<div dir="ltr">i’m sorry this sounds like something different than what this proposal is trying to achieve. Right now I’m just trying to smooth out the singular vs. vector functionality of the existing Swift pointer types. Maybe your idea would be better in a separate proposal?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 4:16 PM, Gor Gyolchanyan <span dir="ltr"><<a href="mailto:gor@gyolchanyan.com" target="_blank">gor@gyolchanyan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>In my understanding, the address manipulation abstractions are as follows:</div><div><ul class="m_4922449594393935133MailOutline"><li>An <b>address</b> is an integer denoting an index into the current <b>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>minimal addressable unit</b> (also known as <b>byte</b>, which is not to be confused with an <b>octet</b>) of the address space is the number of contiguous <b>binary digits</b> (also known as <b>bits</b>) that are uniquely identified by a single address (in most modern architectures that number is <b>8</b>).</li><li>A <b>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>A <b>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>An <b>array</b> is a buffer, representing a contiguous sequence of pointers.</li></ul></div><div><div><br></div><div>Notice, that in above terms the address space is essentially a buffer denoting all available addresses.</div><div><br></div><div>In Swift, the aforementioned concepts correspond to the following types:</div><div><ul class="m_4922449594393935133MailOutline"><li><font color="#008f00" face="PT Mono"><b style="color:rgb(0,0,0);font-family:'Avenir Next'">address</b><span style="color:rgb(0,0,0);font-family:'Avenir Next'">: </span>UnsafeRawPointer</font>, <font color="#008f00" face="PT Mono">UnsafeRawMutablePointer</font><font face="AvenirNext-Regular">, </font><span style="color:rgb(0,143,0);font-family:'PT Mono'">Opaqu<wbr>ePointer</span>.</li><li><font color="#008f00" face="PT Mono"><b style="color:rgb(0,0,0);font-family:'Avenir Next'">buffer</b><span style="color:rgb(0,0,0);font-family:'Avenir Next'">: </span>UnsafeRawBufferPointer</font><wbr>, <font color="#008f00" face="PT Mono">UnsafeMutableRawBufferPointer</font>.</li><li><font color="#008f00" face="PT Mono"><b style="color:rgb(0,0,0);font-family:'Avenir Next'">pointer</b><span style="color:rgb(0,0,0);font-family:'Avenir Next'">: </span>UnsafePointer</font>, <font color="#008f00" face="PT Mono">UnsafeMutablePointer</font><font face="AvenirNext-Regular">, </font><font color="#008f00" face="PT Mono">AutoreleasingUnsafeMutablePoin<wbr>ter</font>.</li><li><font color="#008f00" face="PT Mono"><b style="color:rgb(0,0,0);font-family:'Avenir Next'">array</b><span style="color:rgb(0,0,0);font-family:'Avenir Next'">: </span>UnsafeBufferPointer</font>, <font color="#008f00" face="PT Mono">Un<wbr>safeMutableBufferPointer</font>.</li></ul></div><div><br></div><div>If the unsafe tools of Swift would be redesigned, I’d suggest defining them in the following manner:</div><div><ul class="m_4922449594393935133MailOutline"><li>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>A buffer, that is a random access mutable/immutable collection of addresses, represented as a range.</li><li>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>An array, that is a random access mutable/immutable collection of pointers, represented as a pointer coupled by a count.</li></ul><div><br></div></div><div>So, in the end, we’d have the following set of types: <font color="#009193" face="PT Mono">UnsafeAddress</font>, <font color="#009193" face="PT Mono">UnsafeBuffer</font>, <font color="#009193" face="PT Mono">UnsafePointer</font>, <font color="#009193" face="PT Mono">UnsafeArray</font> (as well as their mutable counter-parts).</div><div>The <font color="#008f00" face="PT Mono">OpaquePointer</font> would then be a thin wrapper around <font color="#009193" face="PT Mono">UnsafeAddress</font> and would probably better off renamed to <font color="#009051" face="PT Mono">CStructPointer</font>, due to the fact that all non-C usages of this type should be replaced by usage of <font color="#009193" face="PT Mono">UnsafeAddress</font>.</div><div>And the <span style="color:rgb(0,143,0);font-family:'PT Mono'">AutoreleasingUnsafeMutable<wbr>Pointer</span> would also be a thing wrapper around <font color="#009193" face="PT Mono">UnsafeAddress</font> with a possible renaming to <font color="#009193" face="PT Mono">NSObjectPointer</font>.</div><div><br></div><div><div><blockquote type="cite"><div><div class="h5"><div>On Jul 12, 2017, at 10:26 PM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_4922449594393935133Apple-interchange-newline"></div></div><div><div><div class="h5"><div dir="ltr"><p>Hi all, I’ve written up a proposal to modify the unsafe pointer API for greater consistency, safety, and ease of use.</p><p>~~~<br></p><p>Swift currently offers two sets of pointer types — singular pointers such as <code>UnsafeMutablePointer</code>, and vector (buffer) pointers such as <code>UnsafeMutable</code><strong><code>Buffer</code></strong><code>Pointer</code>. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement <code>Collection</code> conformance, while singular pointers do not.</p><p>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>number</em> of instances allocated. It’s possible to subscript into a singular pointer, even though they are not real <code>Collection</code>s. Some parts of the current design turn UnsafePointers into downright <em>Dangerous</em>Pointers, leading users to believe that they have allocated or freed memory when in fact, they have not.</p><p>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><<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06" target="_blank">https://gist.github.com/<wbr>kelvin13/<wbr>a9c033193a28b1d4960a89b25fbffb<wbr>06</a>></p><p>~~~<br></p></div></div></div>
______________________________<wbr>_________________<span class=""><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></blockquote></div><br></div></div></div></blockquote></div><br></div>