https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift#L180-L185

apple/swift

swift - The Swift Programming Language

2:54 AM

runtimeがObjC ではない 場合の、 Array の _Buffer がこのオブジェクトだけど

2:54 AM

_EmptyArrayStorage って型もあって

2:54 AM

そっちは

2:54 AM

https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift#L67

apple/swift

swift - The Swift Programming Language

2:55 AM

型パラがなくてstaticElementType がVoid.selfになってる

2:56 AM

internal struct _ContiguousArrayBuffer<Element>は

2:56 AM

https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift#L318

apple/swift

swift - The Swift Programming Language

2:56 AM

空で初期化するときは↑のEmptyArrayStorageを内部で使う

2:57 AM

https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift#L204

apple/swift

swift - The Swift Programming Language

2:57 AM

要素数付きの未初期化(uninitialized memory) バッファを確保するinitは型月の_ContiguousArrayStorage<Element> を使う

2:59 AM

final class _EmptyArrayStorage : _ContiguousArrayStorageBase { } final class _ContiguousArrayStorage<Element> : _ContiguousArrayStorageBase { }

2:59 AM

↑共通の親クラスになってて struct _ContiguousArrayBuffer は、 _ContiguousArrayStorageBase を var _storageでもってる。

3:01 AM

struct Array がAPI層で runtimeによってBufferの型を変える struct ArrayBuffer が可変長バッファの制御をしてる実装の層 class ArrayStorage系が実際の連続メモリを表現してるメモリの層で、空と型付きがあって、要素の型が取れる

3:03 AM

Arrayのinit() では _Buffer のinit() を呼んでるから _EmptyArrayStorage になってそう

3:04 AM

objc runtime の場合は、 ContiguousArrayBufferじゃなくて、 ArrayBufferが使われていて、 ArrayBufferは storage を持ってるので、 Array / Buffer / Storage の３層設計はおなじだけど

3:04 AM

internal typealias _ArrayBridgeStorage = _BridgeStorage<_ContiguousArrayStorageBase, _NSArrayCore> Storageの型がこれになっていて

3:05 AM

Storage の実装として BridgeStorage という概念が出てきて、 _NSArrayCore ・・・

3:05 AM

心配になってきた

3:05 AM

ちゃんとboxingしないでInt並べてるのか・・・？

3:07 AM

 // rawValue is passed inout to _isUnique. Although its value // is unchanged, it must appear mutable to the optimizer. @_versioned internal var rawValue: Builtin.BridgeObject

3:07 AM

 @_inlineable // FIXME(sil-serialize-all) public // @testable var nativeInstance: Native { @inline(__always) get { _sanityCheck(isNative) return Builtin.castReferenceFromBridgeObject(rawValue) } }

3:08 AM

 var objCInstance: ObjC { @inline(__always) get { _sanityCheck(isObjC) return Builtin.castReferenceFromBridgeObject(rawValue) } }

3:08 AM

NativeとObjCは BridgeStorageの型パラメータで、

3:08 AM

rawValueってフィールドに

3:08 AM

どっちかの型のオブジェクトがぶちこまれて

3:08 AM

分岐したりキャストしてなんかEitherっぽくなってる

3:09 AM

internal typealias _ArrayBridgeStorage = _BridgeStorage<_ContiguousArrayStorageBase, _NSArrayCore> で、左側がさっきの pure swift のときの Storage の _ContiguousArrayStorageBase だから、

3:09 AM

大丈夫そうな気がする

3:09 AM

ObjCから来たオブジェクトだとBridgeStorageのrawValueが右側の_NSArrayCoreになっていて

3:10 AM

Swiftから来たオブジェクトだとrawvalueが左側のContiguousASBになっていると予想

3:10 AM

あとはなんか as とかでObjC側にブリッジしたりするときにめんどくさいことが起こるんだろう・・・