<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 30, 2017, at 10:45 AM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">this function <span style="font-family:monospace,monospace" class="">initializeMemory<C:Collection>(as:from:)</span> says it will be removed in Swift 4.0. It is now Swift 4.0. can I remove it?<br class=""></div></div></blockquote><div><br class=""></div>It looks safe to remove. However, the doc comments in the same file should be updated to refer to `initializeMemory<T>(as:from:count:)`.</div><div><br class=""></div><div>+cc Nate Cook</div><div><br class=""></div><div>-Andy</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 30, 2017 at 2:15 AM, Taylor Swift <span dir="ltr" class=""><<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class="h5"><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick <span dir="ltr" class=""><<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 6, 2017, at 10:15 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_-7055782631932014310m_-4760639243348783802m_-7775641474127287529Apple-interchange-newline"><div class=""><div dir="ltr" class="">okay so I think so far what’s been agreed on is <br class=""><br class=""><div class=""><b class="">1</b>. rename “Bytes” to “Memory” in the raw pointer API. Note: this brings the `<span style="font-family:monospace,monospace" class="">copyBytes<C>(from:)</span>` collection method into the scope of this proposal<br class=""></div><div class=""><br class=""></div><b class="">2</b>. change raw offsets to be in terms of bytes, not typed strides. This argument will be called `<span style="font-family:monospace,monospace" class="">atByteOffset:</span>` and will only appear in <span style="font-family:monospace,monospace" class="">UnsafeMutableRawBufferPointer</span>. “<span style="font-family:monospace,monospace" class="">at:</span>” arguments are no longer needed in <span style="font-family:monospace,monospace" class="">UnsafeMutableRawPointer</span>, since we can just use pointer arithmetic now.<br class=""><div class=""><div class=""><br class=""><br class=""></div><b class="">3</b>. move <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span>’s `<span style="font-family:monospace,monospace" class="">at:</span>` arguments to the front of the parameter list. mostly cause any pointer arithmetic happens in the front so structurally we want to mirror that.</div><div class=""><br class=""></div><div class=""><b class="">4</b>. add dual (to:) single element initializers and assigners to <span style="font-family:monospace,monospace" class="">UnsafeMutablePointer</span>, but not <span style="font-family:monospace,monospace" class="">UnsafeMutableRawPointer</span> because it’s apparently not useful there. <span style="font-family:monospace,monospace" class="">`UnsafeMutableRawPointer.initi<wbr class="">alizeMemory<T>(as:</span><span style="font-family:monospace,monospace" class="">repeating:co<wbr class="">unt:)</span>` still loses its default count to prevent confusion with its buffer variant.<br class=""></div><div class=""><br class=""></div><div class=""><b class="">5</b>. memory deallocation on buffer pointers is clearly documented to only be defined behavior when the buffer matches a whole heap block. <br class=""></div></div>
</div></blockquote></div><div class=""><br class=""></div></span>Kelvin,<div class=""><br class=""><div class=""><div class="">Attempting to limit the scope of this proposal backfired. I was hoping to avoid discussing changes to the slice API, instead providing basic functionality within the buffer API itself. However, Dave Abrahams has argued that once the slice API is extended, the positional arguments are extraneous and less clear.</div><div class=""><br class=""></div><div class="">Instead of</div><div class=""><br class=""></div><div class=""> buf.intialize(at: i, from: source)</div><div class=""><br class=""></div><div class="">We want to force a more obvious idiom:</div><div class=""><br class=""></div><div class=""> buf[i..<n].intialize(from: source)</div><div class=""><br class=""></div><div class="">I think this is a reasonable argument and convinced myself that it's possible to extend the slice API. I'm also convinced now that we don't need overloads to handle an UnsafeBufferPointer source, instead we can provide a single generic entry point on both UnsafeMutableBufferPointer and its slice, optimized within the implementation:</div><div class=""><br class=""></div><div class=""> `initialize<S : Sequence>(from: S) -> (S.Iterator, Index)</div><div class=""><br class=""></div><div class="">We can always drop down to the UnsafePointer API to get back to a direct unsafe implementation as a temporary workaround for performance issues.</div><div class=""><br class=""></div><div class="">Let's set aside for now whether we support full or partial initialization/assignment, how to handle moveInitialize, and whether we need to return the Iterator/Index. This is going to require another iteration on swift-evolution, which <b class="">we should discuss in a separate thread</b>. </div><div class=""><br class=""></div><div class="">At this point, I suggest removing the controversial aspects of SE-0184 so that we can put the other changes behind us and focus future discussion around a smaller follow-up proposal.</div><div class=""><br class=""></div><div class="">Here I've summarized the changes that I think could be accepted as-is:</div><div class=""><a href="https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e" target="_blank" class="">https://gist.github.com/atrick<wbr class="">/c1ed7afb598e5cc943bdac7683914<wbr class="">e3e</a></div><div class=""><br class=""></div><div class="">If you amend SE-0184 accordingly and file a new PR, I think it can be quickly approved.</div><div class=""><br class=""></div><div class="">-Andy</div></div><div class=""><br class=""></div></div></div></blockquote></div></div><div class="gmail_extra"><br class=""></div></div></div><div class="gmail_extra">Part one of SE-0184 is <a href="https://github.com/kelvin13/swift-evolution/blob/improved-pointers/proposals/0184a-unsafe-pointers-part-1.md" target="_blank" class="">here as SE-0184 A</a> <br class=""></div><div class="gmail_extra">I’ll implement it tomorrow and then make the PR<br class=""></div></div>
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>