[swift-evolution] Proposal: One-past-end array pointers and convertibility of nil for interaction with C APIs

[Joe Groff]

> On Dec 24, 2015, at 12:48 PM, Árpád Goretity via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Thanks for your answer!
> 
> > I think the thing to do is to make two calls:
> 
> Eeeek, that's exactly what I wanted to avoid (which I actually think is the worst possible solution).
> 
> > The inout-to-pointer is only available to function argument expressions; it's not even considered in a ternary expression here.
> 
> 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.)

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.

> > 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.
> 
> 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.

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.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151225/0533722b/attachment.html>