<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 12, 2016, at 9:27 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On the model itself:</div></div></blockquote><div><br class=""></div><div>Responding to your feedback on the model (thanks!). </div><a href="https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst" class="">https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst</a></div><div>With just one follow up question at the bottom of this email…</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- "thin function, C function, and block function types” <-- block functions are not layout-compatible with C functions, and they <i class="">are</i> layout-compatible with AnyObject. (I mean, they’re both pointers at the moment, but so are non-weak object references.)</div></div></blockquote><div><br class=""></div><div> - pointer types (e.g. ``OpaquePointer``, ``UnsafePointer``)</div><div>- - thin function, C function, and block function types</div><div>+ - block function types and ``AnyObject``</div><div>+ - thin function and C function types</div><div> - imported C types that have the same layout in C</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- "nonresilient structs” <-- nitpick: the term “nonresilient” is not defined here, and isn’t a formal term in the Library Evolution doc. I guess I would actually prefer “fragile” if you needed a generic term across structs and enums, but either way you should put a small definition somewhere in this doc.</div></div></blockquote><div><br class=""></div><div><div> - imported C types that have the same layout in C</div><div>- - nonresilient structs with one stored property and their stored</div><div>+ - fragile structs with one stored property and their stored</div><div> property type</div><div>- - nonresilient enums with one case and their payload type</div><div>+ - fragile enums with one case and their payload type</div><div> </div><div> .. note::</div><div> </div><div>- `Library Evolution Support in Swift`__</div><div>+ "Fragile" enums and structs have strict layout rules that ensure</div><div>+ binary compatibility. `Library Evolution Support in Swift`__</div><div> explains the impact of resilience on object layout.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- "homogeneous tuples, fixed-sized array storage, and homogeneous nonresilient structs in which the element type has no spare bits (structs may be bit packed).” <-- I would leave the structs out of this, even if it’s true. Also, Swift doesn’t have fixed-size arrays at the moment, right?</div></div></blockquote><div><br class=""></div><div><div>Hmm, I think we want to say that raw allocated memory, arrays, homogeneous tuples and structs are layout compatible with 'strideof'. I'll leave out structs for now and this can be hashed out in ABI specs. I want to avoid naming specific API's and I think it's ok to be a bit vague in this (non-ABI) document as long as the intent is obvious:</div><div><br class=""></div><div> - contiguous array storage and homogeneous tuples which </div><div> have the same number and type of elements.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- "In particular, they apply to access that originates from stored property getter and setters, reading from and assigning into inout variables, and reading or assigning subscripts (including the Unsafe[Mutable]Pointer pointee property and subscripts).” I’m unhappy with inout variables being called out specially here. An inout variable should be exactly like a local variable that happens to be stack-allocated, rather than just in registers. Closure captures probably figure in here too.</div></div></blockquote><div><br class=""></div><div><div>Agreed. I'm not sure what I was thinking.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- "unsafeBitCast is valid for pointer to integer conversions” <-- we have better APIs to do this now ('init(bitPattern:)’ in both directions).</div></div></blockquote><div><br class=""></div><div><div>+``unsafeBitCast`` should generally be avoided on pointer types,</div><div>+particularly class types. For pointer to integer conversions,</div><div>+``bitPattern`` initializers are available in both</div><div>+directions. ``unsafeBitCast`` may be used to convert between</div><div>+nondereferenceable pointer types, but as with any conversion to and</div><div>+from opaque pointers, this presents an opportunity for type punning</div><div>+when converting back to a dereferenceable pointer type.</div><div><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- "It is also used internally to convert between nondereferenceable pointer types, which avoids the need to add builtin conversions for all combinations of pointer types.” <-- I’d be happy to get rid of this and just go through Builtin.RawPointer when necessary.</div></div></blockquote><div><br class=""></div><div><div>...I do like to get feedback that eliminating unsafeBitCast is a good thing. I think it should only be needed for genuine reinterpretation of the bits as opposed working around the type system. I'd like to see only a tiny handful of occurrences in stdlib. I have a branch where I've cleaned up many unsafeBitCasts, which never got checked in, so I can spend some time on that again after UnsafePointer changes land. Then maybe we should prohibit it from being called on certain pointer types. For starters AnyObject, UnsafePointer, and UnsafeBytePointer.</div></div><br class=""><blockquote type="cite" class=""><div class=""></div></blockquote><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- On the flip side, I think we <i class="">do</i> need to preserve the ability to reference-cast in order to send Objective-C messages, at least for now. I don’t know how I want to expose that to users, though. (In general it’s probably worth seeing how unsafeBitCast is used in the wild and what we’d recommend instead.)</div></div></blockquote><br class=""></div><div><div>Does ``X as Y`` fail for some reason? We have unchecked versions of ``X as Y`` for performance reasons: ``unsafeDowncast`` and ``_unsafeReferenceCast``.</div><div class=""><br class=""></div><div class="">-Andy</div></div><br class=""></body></html>