<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 5:16 PM, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.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 dir="ltr">I’m fine with most of this<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick <span dir="ltr"><<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><br><div><span class="gmail-m_4706122813625514254gmail-"><blockquote type="cite"><div>On Sep 5, 2017, at 9:53 AM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:</div><br class="gmail-m_4706122813625514254gmail-m_-5448707016195622191Apple-interchange-newline"><div><div dir="ltr">we agreed to deprecate the strided <span style="font-family:monospace,monospace">at:</span>? Note that UnsafeMutableRawBufferPointer would still need a <span style="font-family:monospace,monospace">byteOffset:</span> argument. I’m also still not comfortable with duplicating functionality for the sake of having two names<br></div></div></blockquote><div><br></div></span>I’ll summarize what I think happened in this thread...<br><div><br></div><div>I don't think the suggested copyBytes rename was controversial:</div><div><br></div><div>UMRP (raw pointer):</div><div>--- copyBytes(from:count)</div><div>+++ copyMemory(from:bytes:)</div><div><br></div><div><br></div><div>UMRBP (raw buffer):</div><div>--- copyBytes(from:)</div><div>+++ copyMemory(atByteOffset:from:)</div><div><br></div><div>--- copyBytes<C>(from:)</div><div>+++ copyMemory(from:)</div><div><br></div></div></div></blockquote><div><br></div></span><div>no problem with this<br></div><span class="gmail-"><div> </div><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><br></div><div>In the new raw initializeMemory methods, Xiaodi and I agreed to make</div><div>it more clear that the offset is in terms of `self` rather than</div><div>`from`, and to further reduce ambiguity by forcing manual stride</div><div>computation and using an explicit "offset" label. The call site will</div><div>be just as explicit as dropping down to `baseAddress` but without any</div><div>pointer conversion boilerplate.</div><div><br></div><div>UMRBP (raw buffer):</div><div>+++ func initializeMemory<T>(atByteOffs<wbr>et:as:from:)</div><div>+++ func moveInitializeMemory<T>(atByte<wbr>Offset:as:from:)</div><div><br></div></div></div></blockquote><div><br></div></span><div>Agree, but the label should just be `<span style="font-family:monospace,monospace">atByte:</span>`, not `<span style="font-family:monospace,monospace">atByteOffset:</span>`. after all, we don’t use `<span style="font-family:monospace,monospace">atOffset:</span>` in the strided case; its obvious that it’s an offset</div><span class="gmail-"><div> </div><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><br></div><div>Than, in the one existing initializeMemory method, just drop the strided index.</div><div>It's never used, we want to be consistent in using a byte offset</div><div>for the raw index, and that can be expressed just as easily as pointer</div><div>arithmetic:</div><div><br></div><div>UMRP (raw pointer):</div><div>--- func initializeMemory<T>(as:T.Type, at:Int = 0, count:Int = 1, to:T)</div><div>+++ func initializeMemory<T>(as:T.Type, repeating:T, count:Int = 1)</div><div><br></div><div>Then you can simply leave these methods as-is:</div><div>> func initializeMemory<T>(as:T.Type, from:UnsafePointer<T>, count:Int)</div><div>> func moveInitializeMemory<T>(as:T.T<wbr>ype, from:UnsafeMutablePointer<T>, count:Int) </div><div><br></div></div></div></blockquote><br></span></div><div class="gmail_quote">yes<span class="gmail-"><div> </div><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></div><div>We don't have a consensus, but I think the suggestion to distinguish</div><div>between single value vs. multiple semantics was good. Otherwise,</div><div>adding the default count could be very misleading. Normally, we try to</div><div>minimize surface area, but adding two methods for the single-value case</div><div>avoids ambiguity between the buffer and pointer semantics:</div><div><br></div><div>UMP (pointer)</div><div>--- func initialize(to:count:(=1))</div><div>+++ func initialize(to:)</div><div>+++ func initialize(repeating:count:) // no default count</div><div>+++ func assign(to:)</div><div>+++ func assign(repeating:count:) // no default count</div><div><br></div><div>UMRP (raw pointer):</div><div>--- func initializeMemory<T>(as:at:(=0)<wbr>count:(1)to:)</div><div>+++ func initializeMemory<T>(as:repeati<wbr>ng:count:) // remove default count <br></div></div></div></blockquote><div><br></div></span><div>still extremely suspicious of this but i’m willing to compromise. also there should be an `<span style="font-family:monospace,monospace">initializeMemory<T>(at:to:)</span>` to match the typed methods<br></div></div></div></div></blockquote><div><br></div><div>*<span style="font-family:monospace,monospace">initializeMemory<T>(as:to:)</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class="gmail-"><div> </div><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></div><div><br></div><div>-Andy</div><span class="gmail-m_4706122813625514254gmail-"><div><br></div><blockquote type="cite"><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick <span dir="ltr"><<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>I think we’ve agreed to a few minor updates to this proposal. Since there hasn’t been any other feedback on the thread it may be worth posting an amended proposal so we all know what we’ve agreed on.<div><br></div><div>-Andy<br><div><br><div><blockquote type="cite"><div><div class="gmail-m_4706122813625514254gmail-m_-5448707016195622191h5"><div>On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-interchange-newline"></div></div><div><div><div class="gmail-m_4706122813625514254gmail-m_-5448707016195622191h5"><div><br><div><blockquote type="cite"><div>On Sep 3, 2017, at 8:05 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-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"><div>If we use byte offset, then the<span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span><span style="font-family:monospace,monospace">at</span><span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span>parameter in<span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span><span style="font-family:monospace,monospace">UnsafeMutableRawPointer</span><span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span>sho<wbr>uld be removed, since pointer arithmetic can be used instead (just like with<span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span><span style="font-family:monospace,monospace">UnsafeMutablePointer</span>).</div></div></div></div></blockquote><div dir="auto" 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 dir="auto" 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">I agree that it seems quite sensible to remove the ‘at’ parameter altogether from the UMRP method.</div></div></blockquote><div><br></div>No code in tree or on github is using the `at` argument. I think it can be removed. A fixit should still be possible.</div><div><br><blockquote type="cite"><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"><div>Not convinced moving the<span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span><span style="font-family:monospace,monospace">at:</span><span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span>argument to come before the<span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span><span style="font-family:monospace,monospace">as:</span><span class="gmail-m_4706122813625514254gmail-m_-5448707016195622191m_5074952175224083149Apple-converted-space"> </span>argument is worth it in terms of source breakage.</div></div></div></div></blockquote><div dir="auto" 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 dir="auto" 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">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></div></blockquote></div><div><br></div><div>To be clear, we’re just talking about UnsafeMutableRawBufferPo<wbr>inter.initializeMemory now, so this is purely additive.</div><div>I think the label needs to be `atByteOffset`, and placing it before `as` makes a lot of sense because it no longer depends on the type’s stride. </div><div><br></div><div>-Andy</div></div></div></div><span>______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></blockquote></span></div><br></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>