<div><br><div class="gmail_quote"><div dir="auto">On Sun, Sep 3, 2017 at 21:43 Taylor Swift <<a href="mailto:kelvin13ma@gmail.com">kelvin13ma@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 2, 2017 at 7:53 PM, Andrew Trick <span><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="m_-7565209052189145661gmail-h5"><br><div><blockquote type="cite"><div>On Sep 2, 2017, at 5:34 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-7565209052189145661gmail-m_-1990919025671396673Apple-interchange-newline"><div><div>On Sat, Sep 2, 2017 at 4:41 PM, Andrew Trick <span><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="m_-7565209052189145661gmail-m_-1990919025671396673gmail-"><br><div><blockquote type="cite"><div>On Sep 2, 2017, at 2:06 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_-7565209052189145661gmail-m_-1990919025671396673gmail-m_-7332612120152683601Apple-interchange-newline"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><span class="m_-7565209052189145661gmail-m_-1990919025671396673gmail-m_-7332612120152683601gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div>the subscript doesn’t know about the stride that you want to use. If you want to get rid of the `<span style="font-family:monospace,monospace">at:</span>` ambiguity, you have to get rid of it everywhere, or users will just wind up having to remember two ways (one ambiguous and one less ambiguous) of doing the same thing, instead of one (ambiguous) way of doing it.<br></div></div></div></div></blockquote><div><br></div></span><div>Certainly, that's a good point. On rethink and another re-reading of the proposal, it's unclear to me that the addition of `at` arguments to UnsafeMutablePointer is sufficiently justified by the proposal text. Is it merely that it's shorter than writing `foo + MemoryLayout<T>.stride * offset`? With the ambiguity of `at`, it seems that the current way of writing it, though longer, is certainly less ambiguous.<span class="m_-7565209052189145661gmail-m_-1990919025671396673gmail-m_-7332612120152683601Apple-converted-space"> </span><br></div></div></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Please reread it;<span class="m_-7565209052189145661gmail-m_-1990919025671396673gmail-m_-7332612120152683601Apple-converted-space"> </span><span style="font-family:monospace,monospace">UnsafeMutablePointer</span>’s methods do<span class="m_-7565209052189145661gmail-m_-1990919025671396673gmail-m_-7332612120152683601Apple-converted-space"> </span><i>not</i><span class="m_-7565209052189145661gmail-m_-1990919025671396673gmail-m_-7332612120152683601Apple-converted-space"> </span>use `<span style="font-family:monospace,monospace">at:</span>`.</div></div></blockquote></div><br></span><div>Regarding the typed buffer pointers, I think it is clear by convention, and will be well documented, that the `at` label refers to a position in `self`.</div><div><br></div><div>The raw buffer pointer API isn’t so obvious. Since the `at` refers to `self` it might more logically be a byte offset. Note that `at` as a label name always refers to a strided index.</div><div><br></div><div>This would be a bit more explicit:</div><div>UnsafeRawBufferPointer.initializeMemory(as:T.self, atByteOffset: position * MemoryLayout<T>.stride, from: bufferOfT)</div><div><br></div><div>But possibly less convenient… Since that `at` label currently on UnsafeRawPointer.initializeMemory is almost never used, I don’t think we need to worry too much about convenience.</div><div><br></div><div>That existing `at` label on UnsafeRawPointer.initializeMemory, would also need to be renamed, which is fine.</div></div></blockquote><div><br></div><div>If I may suggest one more incremental improvement in clarity, it would be to move `at[ByteOffset]` to be the first argument; this eliminates the possible reading that we are offsetting the source buffer:</div><div><br></div><div>```</div><div>UnsafeRawBufferPointer.initializeMemory(atByteOffset: position * MemoryLayout<T>.stride, as:T.self, from: bufferOfT)</div><div>```</div></div></div></div>
</div></blockquote></div><br></div></div><div>Sure, that probably makes sense if we decide to go with a byte offset vs. stride index.</div><div>-Andy</div></div></blockquote><div><br></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>If we use byte offset, then the <span style="font-family:monospace,monospace">at</span> parameter in <span style="font-family:monospace,monospace">UnsafeMutableRawPointer</span> should be removed, since pointer arithmetic can be used instead (just like with <span style="font-family:monospace,monospace">UnsafeMutablePointer</span>).</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I agree that it seems quite sensible to remove the ‘at’ parameter altogether from the UMRP method.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div> Not convinced moving the <span style="font-family:monospace,monospace">at:</span> argument to come before the <span style="font-family:monospace,monospace">as:</span> argument is worth it in terms of source breakage.</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Since much of this proposal involves shuffling and relabeling arguments, I’d argue it’s better to break slight more source in one go for the optimal API than to break slightly less for a slightly less optimal API, no? (This is assuming there is agreement that ‘at:as:’ is less prone to misinterpretation than ‘as:at:’.)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div>
</blockquote></div></div>