<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=""><div class="">In my understanding, the address manipulation abstractions are as follows:</div><div class=""><ul class="MailOutline"><li class="">An <b class="">address</b> is an integer denoting an index into the current <b class="">address space</b> (which, in case of a user-space process, is a virtual address space, uniquely allocated by the operating system for that process). The <b class="">minimal addressable unit</b> (also known as <b class="">byte</b>, which is not to be confused with an <b class="">octet</b>) of the address space is the number of contiguous <b class="">binary digits</b> (also known as <b class="">bits</b>) that are uniquely identified by a single address (in most modern architectures that number is <b class="">8</b>).</li><li class="">A <b class="">buffer</b> is a range of addresses, denoting a fragment of the address space, where the delimited contiguous sequence of addresses share common semantics.</li><li class="">A <b class="">pointer</b> is a buffer with some metadata. In statically typed languages the length of the buffer is a compile-time constant and metadata contains type information of the buffer’s contents.</li><li class="">An <b class="">array</b> is a buffer, representing a contiguous sequence of pointers.</li></ul></div><div class=""><div class=""><br class=""></div><div class="">Notice, that in above terms the address space is essentially a buffer denoting all available addresses.</div><div class=""><br class=""></div><div class="">In Swift, the aforementioned concepts correspond to the following types:</div><div class=""><ul class="MailOutline"><li class=""><font face="PT Mono" color="#008f00" class=""><b style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">address</b><span style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">: </span>UnsafeRawPointer</font>, <font face="PT Mono" color="#008f00" class="">UnsafeRawMutablePointer</font><font face="AvenirNext-Regular" class="">, </font><span style="color: rgb(0, 143, 0); font-family: 'PT Mono';" class="">OpaquePointer</span>.</li><li class=""><font face="PT Mono" color="#008f00" class=""><b style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">buffer</b><span style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">: </span>UnsafeRawBufferPointer</font>, <font color="#008f00" face="PT Mono" class="">UnsafeMutableRawBufferPointer</font>.</li><li class=""><font face="PT Mono" color="#008f00" class=""><b style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">pointer</b><span style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">: </span>UnsafePointer</font>, <font face="PT Mono" color="#008f00" class="">UnsafeMutablePointer</font><font face="AvenirNext-Regular" class="">, </font><font face="PT Mono" color="#008f00" class="">AutoreleasingUnsafeMutablePointer</font>.</li><li class=""><font face="PT Mono" color="#008f00" class=""><b style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">array</b><span style="color: rgb(0, 0, 0); font-family: 'Avenir Next';" class="">: </span>UnsafeBufferPointer</font>, <font color="#008f00" face="PT Mono" class="">UnsafeMutableBufferPointer</font>.</li></ul></div><div class=""><br class=""></div><div class="">If the unsafe tools of Swift would be redesigned, I’d suggest defining them in the following manner:</div><div class=""><ul class="MailOutline"><li class="">A comparable and hashable address that can be added an address offset, and subtracted another address to get an address offset. An address would also expose a mutable/immutable property that is the byte referred to by that address.</li><li class="">A buffer, that is a random access mutable/immutable collection of addresses, represented as a range.</li><li class="">A pointer, that is a generic type that is represented by an address and the inherent type information of its generic parameter. The pointer would only expose the address in the form of a buffer and would expose the referred object in the form of a mutable/immutable property of the respective type.</li><li class="">An array, that is a random access mutable/immutable collection of pointers, represented as a pointer coupled by a count.</li></ul><div class=""><br class=""></div></div><div class="">So, in the end, we’d have the following set of types: <font face="PT Mono" color="#009193" class="">UnsafeAddress</font>, <font face="PT Mono" color="#009193" class="">UnsafeBuffer</font>, <font face="PT Mono" color="#009193" class="">UnsafePointer</font>, <font face="PT Mono" color="#009193" class="">UnsafeArray</font> (as well as their mutable counter-parts).</div><div class="">The <font face="PT Mono" color="#008f00" class="">OpaquePointer</font> would then be a thin wrapper around <font face="PT Mono" color="#009193" class="">UnsafeAddress</font> and would probably better off renamed to <font face="PT Mono" color="#009051" class="">CStructPointer</font>, due to the fact that all non-C usages of this type should be replaced by usage of <font face="PT Mono" color="#009193" class="">UnsafeAddress</font>.</div><div class="">And the <span style="color: rgb(0, 143, 0); font-family: 'PT Mono';" class="">AutoreleasingUnsafeMutablePointer</span> would also be a thing wrapper around <font face="PT Mono" color="#009193" class="">UnsafeAddress</font> with a possible renaming to <font face="PT Mono" color="#009193" class="">NSObjectPointer</font>.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jul 12, 2017, at 10:26 PM, Taylor Swift 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=""><div dir="ltr" class=""><p class="">Hi all, I’ve written up a proposal to modify the unsafe pointer API for greater consistency, safety, and ease of use.</p><p class="">~~~<br class=""></p><p class="">Swift currently offers two sets of pointer types — singular pointers such as <code class="">UnsafeMutablePointer</code>, and vector (buffer) pointers such as <code class="">UnsafeMutable</code><strong class=""><code class="">Buffer</code></strong><code class="">Pointer</code>. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement <code class="">Collection</code> conformance, while singular pointers do not.</p><p class="">However, some aspects of the pointer design contradict these implied
roles. It is possible to allocate an arbitrary number of instances from a
type method on a singular pointer, but not from a buffer pointer. The
result of such an operation returns a singular pointer, even though a
buffer pointer would be more appropriate to capture the information
about the <em class="">number</em> of instances allocated. It’s possible to subscript into a singular pointer, even though they are not real <code class="">Collection</code>s. Some parts of the current design turn UnsafePointers into downright <em class="">Dangerous</em>Pointers, leading users to believe that they have allocated or freed memory when in fact, they have not.</p><p class="">This proposal seeks to iron out these inconsistencies, and offer a
more convenient, more sensible, and less bug-prone API for Swift
pointers.</p><p class=""><<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06" class="">https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06</a>></p><p class="">~~~<br class=""></p></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>