<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 20, 2017, at 6:03 PM, 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=""><div class="">New draft of the proposal is up here: <<a href="https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md" class="">https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md</a>><br class=""><br class=""></div>Important changes <a href="https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md#proposed-solution" class="">start here</a>.<br class=""></div></div></blockquote><div><br class=""></div><div>This should be brought to the attention of swift-evolution:</div><div><br class=""></div><blockquote type="cite" class="">The old `deallocate(capacity:)` method should be marked as `unavailable` since it currently encourages dangerously incorrect code. This avoids misleading future users, forces current users to address this potentially catastrophic memory bug, and leaves the possibility open for us to add a `deallocate(capacity:)` method in the future, or perhaps even a `reallocate(toCapacity:)` method.<br class=""></blockquote><div class=""><br class=""></div><div class="">I can’t defend breaking existing source without having seen real code that was actually written incorrectly. I don’t see the downside of using the same deprecation strategy as the other changes. I expect code that was already written to be correct and future code to not call the deprecated API.</div><div class=""><br class=""></div><div class="">-Andy</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 20, 2017 at 1:40 PM, Kelvin Ma <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="auto" class=""><div class=""></div><div class="">actually never mind that, UnsafeMutablePointer should be the only type to not support at: arguments since offsetting them is easy with +.</div><div class=""><div class="h5"><div class=""><br class="">On Aug 20, 2017, at 12:12 AM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Aug 19, 2017 at 10:28 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br class=""><div class=""><span class="m_-6246011967547547910gmail-"><blockquote type="cite" class=""><div class="">On Aug 19, 2017, at 6:42 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_-6246011967547547910gmail-m_2409133619295283737Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Aug 19, 2017 at 9:31 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br class=""><div class=""><span class="m_-6246011967547547910gmail-m_2409133619295283737gmail-"><blockquote type="cite" class=""><div class="">On Aug 19, 2017, at 6:16 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_-6246011967547547910gmail-m_2409133619295283737gmail-m_321540164580745063Apple-interchange-newline"><div class=""><div dir="ltr" class="">What you’re describing is basically an earlier version of the proposal which had a slightly weaker precondition (source >= destination) than yours (source == destination). That one basically ignored the Sequence methods at the expense of greater API surface area.<br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class="">The Sequence methods don’t provide the simpler, more convenient form of initialization/deinitializatio<wbr class="">n that I thought you wanted. I see two reasonable options.</div><div class=""><br class=""></div><div class="">1. Don’t provide any new buffer initialization/deinitializatio<wbr class="">n convenience. i.e. drop UsafeMutableBufferPointer moveInitialize, moveAssign, and deinitialize from your proposal.</div><div class=""><br class=""></div><div class="">2. Provide the full set of convenience methods: initialize, assign, moveInitialize, and moveAssign assuming self.count==source.count. And provide deinitialize() to be used only in conjunction with those new initializers.</div><div class=""><br class=""></div><div class="">The question is really whether those new methods are going to significantly simplify your code. If not, #1 is the conservative choice. Don't provide convenience which could be misused. Put off solving that problem until we can design a new move-only buffer type that tracks partially initialized state.</div><div class=""><br class=""></div><div class="">-Andy <br class=""></div></div><br class=""></div></blockquote></div></div><br class="">I’m not sure the answer is to just omit methods from <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span> since most of the original complaints circulated around having to un-nil <span style="font-family:monospace,monospace" class="">baseAddress</span> to do anything with them.<br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class="">I know un-nil’ing baseAddress is horrible, but I don’t think working around that is an important goal yet. Eventually there will be a much safer, more convenient mechanism for manual allocation that doesn’t involve “pointers". I also considered adding API surface to UnsafeMutableBufferPointer.Sli<wbr class="">ce, but that’s beyond what we should do now and may also become irrelevant when we have a more sophisticated buffer type. </div><span class="m_-6246011967547547910gmail-"><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">What if only unary methods should be added to <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span> without <span style="font-family:monospace,monospace" class="">count:</span>, meaning:<div class="gmail_extra"><br class=""></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">initialize(repeating:)</span></div></div></div></blockquote><div class=""><br class=""></div></span>I actually have no problem with this one... except that it could be confused with UnsafeMutablePointer.initializ<wbr class="">e(repeating:), but I’ll ignore that since we already discussed it.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">assign(repeating:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">deinitialize()</span></div></div></div></blockquote><div class=""><br class=""></div><div class="">These are fine only if we have use cases that warrant them AND those use cases are expected to fully initialize the buffer, either via initialize(repeating:) or initialize(from: buffer) with precondition(source.count==sel<wbr class="">f.count). They don’t really make sense for the use case that I’m familiar with. Without clear motivating code patterns, they aren’t worth the risk. “API Completeness” doesn’t have intrinsic value.</div></div></div></blockquote><div class=""><br class=""></div><div class="">An example use for assign(repeating:) would be to zero out an image buffer.<br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><span class="m_-6246011967547547910gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">and the other methods should take both an <i class="">offset</i> parameter instead of a count parameter:</div><div class="gmail_extra"><span style="font-family:monospace,monospace" class=""><br class=""></span></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">initialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">assign(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">moveInitialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">moveAssign(from:at:)</span></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">which provides maximum explicitness. This requires improvements to buffer pointer slicing though. But I’m not a fan of the mission creep that’s working into this proposal (i only originally wrote the thing to get <span style="font-family:monospace,monospace" class="">allocate(capacity:)</span> and <span style="font-family:monospace,monospace" class="">deallocate()</span> into <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span>!)</div></div>
</div></blockquote><br class=""></span></div><div class="">I’m open to that, with source.count <= self.count + index. They are potentially ambiguous (the `at` could refer to a source index) but consistent with the idea that this API is for copying an entire source buffer into a slice of the destination buffer. Again, we need to find real code that benefits from this, but I expect the stdlib could use these.</div><div class=""><br class=""></div><div class="">-Andy</div></div></blockquote></div></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">The more I think the more I believe using <span style="font-family:monospace,monospace" class="">from:at:</span> is the right approach. The only problem is that it would have to be written as a generic on <span style="font-family:monospace,monospace" class="">Collection</span> or <span style="font-family:monospace,monospace" class="">Sequence</span> to avoid having to provide up to 4 overloads for each operation, since we would want these to work well with buffer slices as well as buffers themselves. That puts them uncomfortably close to the turf of the existing buffer pointer <span style="font-family:monospace,monospace" class="">Sequence</span> API though.<br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Or we could make <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span> its own slice type. Right now <span style="font-family:monospace,monospace" class="">MutableRandomAccessSlice<<wbr class="">UnsafeMutableBufferPointer<<wbr class="">Element>></span> takes up 4 words of storage when it really only needs two.<br class=""></div></div>
</div></blockquote></div></div><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><span class=""><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></span><br class=""></span></div></blockquote></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>