<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 Dec 24, 2015, at 12:48 PM, Árpád Goretity via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="font-size:12.8px" class="">Thanks for your answer!</div><span class="im" style="font-size:12.8px"><div class=""><br class=""></div>> <span style="font-size:12.8px" class="">I think the thing to do is to make two calls:</span><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div></span><div style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">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" class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">> </span><span style="font-size:12.8px" class="">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" class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">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 class=""></div><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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">> </span><span style="font-size:12.8px" class="">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" class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">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 class=""></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><div><br class=""></div><div>-Joe</div><br class=""></body></html>