<div dir="ltr">> <span style="font-size:12.8px">ObjC bridging means that an array might really be an opaque NSArray subclass we can't get a buffer from</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Ah, I totally forgot about that. (not trying to be a pain, but NSArray could as well expose its buffer… if and only if the subclass in use doesn't do the usual circular buffer optimization. But then again, I see why this is difficult, so let's just leave it there.)<br></span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">By fencing the pointer's validity to a particular scope we can also keep array value semantics safe</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Sure thing. So does this then mean that the kind of "unsafe/real address-of" operation can't be generally realized?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 25, 2015 at 9:00 PM, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Dec 24, 2015, at 12:48 PM, Árpád Goretity via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div style="font-size:12.8px">Thanks for your answer!</div><span style="font-size:12.8px"><div><br></div>> <span style="font-size:12.8px">I think the thing to do is to make two calls:</span><div><span style="font-size:12.8px"><br></span></div></span><div style="font-size:12.8px"><span style="font-size:12.8px">Eeeek, that's exactly what I wanted to avoid (which I actually think is the worst possible solution).</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">The inout-to-pointer is only available to function argument expressions; it's not even considered in a ternary expression here.</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Yes, I realized that (in fact I think the diagnostic makes this quite clear). I understand *why* it does not currently work, I'm merely suggesting that I think it *should* work. (It might be too hard to implement, just my opinion.)</span></div></div></div></blockquote><div><br></div></span><div>Well, it might be a bit more humane to have a rule similar to C++ temporaries, where temporary references are guaranteed valid for the duration of the statement in which the temporary was produced. We could say that pointer bridging conversions guarantee the buffer for the duration of the statement rather than the immediate call.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">In general, we can't support fully first-class pointers into managed Swift entities like Array and properties, without breaking the encapsulation of those abstractions.</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Yes, that's kind of obvious – what I am actually trying to suggest is that unsafe is already unsafe, so it might be OK to "break the encapsulation", for example by returning a pointer to the internal buffer without introducing a temporary.</span></div></div></div></blockquote><br></span></div><div>The withUnsafe*Pointer operations do try to reuse existing buffers when there is a buffer, and it's safe to mutate. Copy-on-write means we might need to copy before yielding the pointer to avoid mutating shared state, and ObjC bridging means that an array might really be an opaque NSArray subclass we can't get a buffer from. By fencing the pointer's validity to a particular scope we can also keep array value semantics safe when the array ends up shared after the pointer's been taken.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Joe</div><br></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#000000" face="monospace" size="3">Author of the Sparkling language</font><div><font color="#000000" face="monospace" size="3"><a href="http://h2co3.org" target="_blank">http://h2co3.org/</a><br></font></div><div><font color="#000000" face="monospace" size="3"><br></font></div></div></div>
</div>