<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 Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you!<br class="">&lt;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md</a>&gt;<br class=""></div></div></blockquote></div><div><br class=""></div><div><div>Excellent. Thanks for patiently iterating on this. I know it's time consuming.</div><div><br class=""></div><div>&gt; This differs from the previous draft of this proposal, in that this</div><div>&gt; expansion is more additive and less source-breaking, preserving the</div><div>&gt; much of the sized API present on UnsafeMutablePointer.</div><div><br class=""></div><div>Yay!</div><div><br class=""></div><div>&gt; For the binary operations assign(from:), moveAssign(from:),</div><div>&gt; moveInitialize(from:), and initialize(from:), it is assumed that the</div><div>&gt; other buffer pointer contains at least as many elements as self does.</div><div><br class=""></div><div>Uh-oh! This should be consistent with</div><div>UnsafeRawBufferPointer.copy(from:bytes:) (the raw version of</div><div>assign/initialize(from:)). There we assume no data is dropped and</div><div>allow an uninitalized buffer tail. What was your rationale for the</div><div>opposite choice and how can we reconcile these APIs?</div><div><br class=""></div><div>&gt; add a default value of 1 to all size parameters on</div><div>&gt; UnsafeMutablePointer and applicable size parameters on</div><div>&gt; UnsafeMutableRawPointer</div><div><br class=""></div><div>I'm generally ok with this if you have seen the benefit of it in real</div><div>code. However, I do not think any `repeating:` methods should have a</div><div>default count.</div><div><br class=""></div><div>&gt; avoids the contradictory and inconsistent use of count to represent a byte quantity</div><div><br class=""></div><div>Background: Whether you consider an API consistent depends on how you</div><div>prioritize the guidelines. Here you've taken guidelines that I started</div><div>to use for new raw pointer APIs and given them higher priority than</div><div>other guidelines, in this case having the `count` initializer label match</div><div>the name of the public property being initialized. I think your change</div><div>is an improvement, but there was nothing accidental about the previous</div><div>API.</div><div><br class=""></div><div>&gt; UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)</div><div><br class=""></div><div>Well, I think it's somewhat ridiculous for users to write this every time they allocate a buffer:</div><div><br class=""></div><div>`UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: MemoryLayout&lt;UInt&gt;.alignment)`</div><div><br class=""></div><div>If anyone reading the code is unsure about the Swift API's alignment</div><div>guarantee, it's trivial to check the API docs.</div><div><br class=""></div><div>You could introduce a clearly documented default `alignedTo`</div><div>argument. The reason I didn't do that is that the runtime won't</div><div>respect it anyway. But I think it would be fair to go ahead with the</div><div>API and file a bug against the runtime.</div><div><br class=""></div><div>&gt; and initializeMemory&lt;Element&gt;(as:at:repeating:count:),</div><div>&gt; initializeMemory&lt;Element&gt;(as:from:count:)</div><div>&gt; moveInitializeMemory&lt;Element&gt;(as:from:count:), and</div><div>&gt; bindMemory&lt;Element&gt;(to:count:) to UnsafeMutableRawBufferPointer</div><div><br class=""></div><div>I think you should move the raw pointer changes to a separate bullet point.</div><div><br class=""></div><div>Presumably the raw buffer capacity must match or exceed count * stride?</div><div class=""><br class=""></div><div class="">-Andy</div></div></body></html>