<div dir="ltr"><div><div>How disruptive would it be to move the `<span style="font-family:monospace,monospace">at:</span>` parameter in `<span style="font-family:monospace,monospace">UnsafeMutableRawPointer.initializeMemory(as:at:count:to:)</span>` to a method in `<span style="font-family:monospace,monospace">UnsafeMutableRawBufferPointer</span>`?<br><br></div><span style="font-family:monospace,monospace">(raw_ptr + 16).initializeMemory(as: UInt64.self, from: source, count: 5)</span><br><br></div>instead of <br><br><span style="font-family:monospace,monospace">raw_ptr.initializeMemory(as: UInt64.self, at: 2, from: source, count: 5)</span><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 20, 2017 at 12:12 AM, Taylor Swift via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Aug 19, 2017 at 10:28 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="m_3227816305705655984gmail-"><blockquote type="cite"><div>On Aug 19, 2017, at 6:42 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_3227816305705655984gmail-m_2409133619295283737Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 19, 2017 at 9:31 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="m_3227816305705655984gmail-m_2409133619295283737gmail-"><blockquote type="cite"><div>On Aug 19, 2017, at 6:16 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_3227816305705655984gmail-m_2409133619295283737gmail-m_321540164580745063Apple-interchange-newline"><div><div dir="ltr">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></div></div></blockquote><div><br></div></span><div>The Sequence methods don’t provide the simpler, more convenient form of initialization/deinitializatio<wbr>n that I thought you wanted. I see two reasonable options.</div><div><br></div><div>1. Don’t provide any new buffer initialization/deinitializatio<wbr>n convenience. i.e. drop UsafeMutableBufferPointer moveInitialize, moveAssign, and deinitialize from your proposal.</div><div><br></div><div>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><br></div><div>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><br></div><div>-Andy <br></div></div><br></div></blockquote></div></div><br>I’m not sure the answer is to just omit methods from <span style="font-family:monospace,monospace">UnsafeMutableBufferPointer</span> since most of the original complaints circulated around having to un-nil <span style="font-family:monospace,monospace">baseAddress</span> to do anything with them.<br></div></div></blockquote><div><br></div></span><div>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>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_3227816305705655984gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr">What if only unary methods should be added to <span style="font-family:monospace,monospace">UnsafeMutableBufferPointer</span> without <span style="font-family:monospace,monospace">count:</span>, meaning:<div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-family:monospace,monospace">initialize(repeating:)</span></div></div></div></blockquote><div><br></div></span>I actually have no problem with this one... except that it could be confused with UnsafeMutablePointer.initializ<wbr>e(repeating:), but I’ll ignore that since we already discussed it.</div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><span style="font-family:monospace,monospace">assign(repeating:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">deinitialize()</span></div></div></div></blockquote><div><br></div><div>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>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><br></div></span><span class=""><div>An example use for assign(repeating:) would be to zero out an image buffer.<br></div><div> </div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><span class="m_3227816305705655984gmail-"><br><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">and the other methods should take both an <i>offset</i> parameter instead of a count parameter:</div><div class="gmail_extra"><span style="font-family:monospace,monospace"><br></span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">initialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">assign(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">moveInitialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">moveAssign(from:at:)</span></div><div class="gmail_extra"><br></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">allocate(capacity:)</span> and <span style="font-family:monospace,monospace">deallocate()</span> into <span style="font-family:monospace,monospace">UnsafeMutableBufferPointer</span>!)</div></div>
</div></blockquote><br></span></span></div><span class=""><div>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><br></div><div>-Andy</div></span></div></blockquote></div></div><div class="gmail_extra"><br></div><span class=""><div class="gmail_extra">The more I think the more I believe using <span style="font-family:monospace,monospace">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">Collection</span> or <span style="font-family:monospace,monospace">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">Sequence</span> API though.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Or we could make <span style="font-family:monospace,monospace">UnsafeMutableBufferPointer</span> its own slice type. Right now <span style="font-family:monospace,monospace">MutableRandomAccessSlice<<wbr>UnsafeMutableBufferPointer<<wbr>Element>></span> takes up 4 words of storage when it really only needs two.<br></div></span></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>