<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 8, 2017, at 11:10 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=""><br class=""><div class="gmail_extra">On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick <span dir="ltr" class=""><<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>></span> wrote:<br class=""><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 style="overflow-wrap: break-word;" class=""><br class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Aug 8, 2017, at 8:44 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="gmail-m_2532167022362721963Apple-interchange-newline"><div class=""><div dir="ltr" class="">cool,, as for <span style="font-family:monospace,monospace" class="">UnsafeMutableRawBufferPointer.<wbr class="">copy(from:bytes:)</span>, I cannot find such a function anywhere in the API. There is <a href="https://developer.apple.com/documentation/swift/unsafemutablerawbufferpointer/2635415-copybytes" target="_blank" class=""><span style="font-family:monospace,monospace" class="">copyBytes(from:)</span></a>, but the documentation is messed up and mentions a nonexistent <span style="font-family:monospace,monospace" class="">count:</span> argument over and over again. The documentation also doesn’t mention what happens if there is a length mismatch, so users are effectively relying on an implementation detail. I don’t know how to best resolve this.<br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class="">We currently have `<wbr class="">UnsafeMutableRawBufferPointer.<wbr class="">copyBytes(from:)`. I don’t think your proposal changes that. The current docs refer to the `source` parameter, which is correct. Docs refer to the parameter name, not the label name. So `source.count` is the size of the input. I was pointing out that it has the semantics: `debugAssert(source.count <= self.count)`.</div><div class=""><br class=""></div><div class="">Your proposal changes `UnsafeRawPointer.copyBytes(<wbr class="">from:count:)` to `UnsafeRawPointer.copy(from:<wbr class="">bytes:)`. Originally we wanted to those API names to match, but I’m fine with your change. What is more important is that the semantics are the same as `copyBytes(from:)`. Furthermore, any new methods that you add that copy into a raw buffer (e.g. initializeMemory(as:from:<wbr class="">count:)) should have similar behavior.</div><div class=""><br class=""></div></div></div></blockquote><div class=""> </div><div class="">I’m fine with switching to taking the <span style="font-family:monospace,monospace" class="">count</span> from the source, though I think taking the <span style="font-family:monospace,monospace" class="">count</span>
from the destination is slightly better because 1) the use cases I
mentioned in the other email, and 2) all the other memorystate functions
use <span style="font-family:monospace,monospace" class="">self.count</span> instead of <span style="font-family:monospace,monospace" class="">source.count</span>, if they take a <span style="font-family:monospace,monospace" class="">source</span> argument. But being consistent with the raw pointer version is more important.</div></div></div></div></div></blockquote><div><br class=""></div>If it’s copying from a buffer it should not take a count, if it’s copying from a pointer it obviously needs to take a count. What I mean by the two versions being named consistently is simply that they’re both named `copyBytes`. That really isn’t important though. The overflow/underflow semantics being consistent are important.</div><div><br class=""></div><div>(Incidentally, the reason “bytes” needs to be in the somewhere name is because this method isn’t capable of copying nontrivial values)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Should the methods that don’t deal with raw buffers also be modified to use the source argument (i.e. UnsafeMutableBufferPointer.initialize(from:))?<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>I’m not sure what you mean by this. It also allows the destination to be larger than the source. Initializing from a sequence does not trap on overflow because we can’t guarantee the size of the sequence ahead of time. When I talk about consistent overflow/underflow semantics, I’m only talking about initializing one unsafe buffer/pointer from another unsafe buffer/pointer.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Also, was there a reason why <span style="font-family:monospace,monospace" class="">UnsafeMutableRawBufferPointer.copyBytes(from:)</span> uses the source’s count instead of its own? Right now this behavior is “technically” undocumented behavior (as the public docs haven’t been updated) so if there was ever a time to change it, now would be it.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>Mainly because partial initialization is more expected than dropping data on the floor. Ultimately, this should be whatever typical developers would expect the behavior to be. I would be very hesitant to change the behavior now though.</div><div><br class=""></div><div>-Andy</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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 style="overflow-wrap: break-word;" class=""><div class=""><div class=""></div><div class="">—</div><div class=""><br class=""></div><div class="">Another thing. The initialization methods that you’re adding to `UnsafeRawPointer` and `UnsafeRawBufferPointer` should return typed `UnsafePointer<Element>` and `UnsafeBufferPointer<Element>` respectively.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I’ll fix that once the current <a href="https://github.com/apple/swift-evolution/pull/741" class="">pending edit</a> gets merged.<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 style="overflow-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">-Andy</div><span class="gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 8, 2017 at 11:33 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 style="overflow-wrap: break-word;" class=""><div class=""><div class="gmail-m_2532167022362721963h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 8, 2017, at 8:29 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="gmail-m_2532167022362721963m_-6986739811646066256Apple-interchange-newline"><div class=""><div class="gmail_extra" 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 class="gmail-m_2532167022362721963m_-6986739811646066256Apple-interchange-newline"><br class=""><div class="gmail_quote">On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick<span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>></span><span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span>wrote<wbr class="">:<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 style="overflow-wrap: break-word;" class=""><div class=""><div class="gmail-m_2532167022362721963m_-6986739811646066256h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 8, 2017, at 6:51 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="gmail-m_2532167022362721963m_-6986739811646066256m_-67376284151341790Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick<span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>></span><span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span>wrote<wbr class="">:<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 style="overflow-wrap: break-word;" class=""><div class=""><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div 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"><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=""><div class="">> UnsafeMutableRawBufferPointer.<wbr class="">allocate(bytes:alignedTo:)</div><div class=""><br class=""></div><div class="">Well, I think it's somewhat ridiculous for users to write this every time they allocate a buffer:</div><div class=""><br class=""></div><div class="">`UnsafeMutableRawBufferPointer<wbr class="">.allocate(bytes: size, alignedTo: MemoryLayout<UInt>.alignment)`</div><div class=""><br class=""></div><div class="">If anyone reading the code is unsure about the Swift API's alignment</div><div class="">guarantee, it's trivial to check the API docs.</div><div class=""><br class=""></div><div class="">You could introduce a clearly documented default `alignedTo`</div><div class="">argument. The reason I didn't do that is that the runtime won't</div><div class="">respect it anyway. But I think it would be fair to go ahead with the</div><div class="">API and file a bug against the runtime.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Default argument of<span class="gmail-m_2532167022362721963m_-6986739811646066256m_-67376284151341790m_7821494737473580892Apple-converted-space"> </span><span style="font-family:monospace,monospace" class="">MemoryLayout<Int>.alignment</span><span class="gmail-m_2532167022362721963m_-6986739811646066256m_-67376284151341790m_7821494737473580892Apple-converted-space"><wbr class=""> </span>is the way to go but as you said i don’t know if that is actually allowed/works. An alternative is to have two allocate methods each, one that takes an alignment argument and one that doesn’t (and aligns to pointer alignment) but that feels inelegant. Default arguments would be better.<br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class="">Default argument makes sense to me too. Then the raw buffer pointer and regular raw pointer APIs can be consistent with each other.</div><div class=""><br class=""></div><div class="">Runtime bug:<span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span><a href="https://bugs.swift.org/browse/SR-5664" target="_blank" class="">https://bugs.swift.org/br<wbr class="">owse/SR-5664</a></div><span class=""></span><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">yikes i was not aware of this. I don’t think it’s bad enough to warrant dropping the argument like with<span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span><span style="font-family:monospace,monospace" class="">deallocate(capacity:)</span><span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span>but I can imagine bad things happening to code that crams extra inhabitants into pointers.<br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div><div class="">If we ever need to do pointer adjustment during deallocation to accommodate alignment, then I think the Swift runtime can track that. I see no reason to muddy the UnsafeRawPointer API with it. So, I agree with your proposed change to drop `alignedTo` there.</div><div class=""><br class=""></div><div class="">-Andy</div></div></blockquote></div><br class=""></div><div class="gmail_extra" 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">oh lol I was talking about assuming the pointer returned by<span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span><span style="font-family:monospace,monospace" class="">allocate(bytes:alignedTo:)</span><span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span><wbr class="">is a multiple of<span class="gmail-m_2532167022362721963m_-6986739811646066256Apple-converted-space"> </span><span style="font-family:monospace,monospace" class="">alignedTo</span>. Some code might be relying on the last few bits of the pointer being zero; i.e. sticking bit flags there like how some implementations store the red/black color information in a red-black tree node.</div></div></blockquote><br class=""></div></div></div><div class="">Oh, sure. But I think it will be easy to fix the runtime. We could probably do it before the proposal is accepted if necessary.</div><div class="">-Andy</div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>