<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span 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; float: none; display: inline !important;" class="">I have a pile of naming quibbles; rather than describe them all in prose (which turned into a mess), I've annotated parts of the "Full UnsafeRawPointer API" section in a gist: <</span><a href="https://gist.github.com/brentdax/8f4ed4decafc1d18c4441092baa13cfe" 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;" class="">https://gist.github.com/brentdax/8f4ed4decafc1d18c4441092baa13cfe</a><span 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; float: none; display: inline !important;" class="">>.</span><br 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;" class=""><br 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;" class=""></div></blockquote></div><br class=""><div class=""><div class="">I mostly agree with Brent's naming suggestions below. Anyone else want to weigh in?</div><div class=""><a href="https://github.com/apple/swift-evolution/pull/410" class="">https://github.com/apple/swift-evolution/pull/410</a></div><div class=""><br class=""></div><div class="">> it's not clear that these operations are </div><div class="">> nonmutating. I prefer `casting` because it's clearer about that.</div><div class=""><br class=""></div><div class="">Now we have:</div><div class=""><br class=""></div><div class=""> func bindMemory<T>(to: T.Type, capacity: Int) -> UnsafeMutablePointer<T></div><div class=""><br class=""></div><div class=""> func assumingMemoryBound<T>(to: T.Type) -> UnsafeMutablePointer<T></div><div class=""><br class=""></div><div class=""> func withMemoryRebound<T>(to: T.Type, capacity count: Int,</div><div class=""> _ body: @noescape (UnsafeMutablePointer<T>) throws -> ()) rethrows</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">"bind" is active. It has important side effects.</div><div class="">"assuming" is passive; it's just a "cast".</div><div class="">"withMemoryRebound" temporarily rebinds the type, but leaves it in its original state. "with" is sufficient to imply that the closure may mutate state.</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class=""> // In addition to the above point, I don't think "to" belongs in </div><div class=""> // front of "contiguous" here. It makes sense with the verbs in </div><div class=""> // `load` and `storeRaw` below, but not with this verb.</div><div class=""> // </div><div class=""> // I also think `contiguous` basically implies `Index`, so we can </div><div class=""> // just use `at`. Yes, I know about the `load` method with </div><div class=""> // `atByteOffset`.</div><div class=""> // </div><div class=""> // func initialize<T>(toContiguous: T.Type, atIndex: Int, with: T)</div><div class=""> // -> UnsafeMutablePointer<T></div><div class=""> func initialize<T>(contiguous: T.Type, at: Int, to: T)</div><div class=""> -> UnsafeMutablePointer<T></div><div class=""><br class=""></div><div class="">This is a purely additive API that I'm personally in favor of dropping if it's confusing, but it was requested as a convenience...</div><div class=""><br class=""></div><div class="">The "toContiguous" was to avoid implying that a sequence of elements is being initialized, as opposed to a single element. "atIndex" was also suggested as a clarification. In hindsight I don't think either are likely to improve clarity in practice. I'm inclined to go with your suggestion, and if anyone thinks it's confusing we should drop the API for now:</div><div class=""><br class=""></div><div class=""> func initialize<T>(contiguous: T.Type, at: Int, to: T)</div><div class=""> -> UnsafeMutablePointer<T></div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class=""> // A little backwards, but `as` here is to support a more fluent </div><div class=""> // `storeRaw` equivalent.</div><div class=""> //</div><div class=""> // func load<T>(_: T.Type) -> T</div><div class=""> // func load<T>(_: T.Type, atByteOffset: Int) -> T</div><div class=""> func load<T>(as: T.Type) -> T</div><div class=""> func load<T>(fromByteOffset: Int, as: T.Type) -> T</div><div class=""> // func load<T>(fromContiguous: T.Type, atIndex: Int) -> T</div><div class=""> func load<T>(fromContiguous: T.Type, at: Int) -> T</div><div class=""><br class=""></div><div class=""> // I'm reversing the arguments here because the thing being stored is </div><div class=""> // the obvious direct object of the verb "store".</div><div class=""> // </div><div class=""> // func storeRaw<T>(_: T.Type, with: T)</div><div class=""> // func storeRaw<T>(toContiguous: T.Type, at: Int, with: T)</div><div class=""> func storeRaw<T>(_: T, as: T.Type)</div><div class=""> func storeRaw<T>(_: T, toContiguous: T.Type, at: Int)</div><div class=""><br class=""></div><div class="">I agree. Giving `load` and "as" label makes sense because the in-memory type may be different than the loaded type.</div><div class=""><br class=""></div><div class="">I strongly prefer your version of "storeRaw".</div></div><div class=""><br class=""></div><div class="">-Andy</div></body></html>