> ObjC bridging means that an array might really be an opaque NSArray subclass we can't get a buffer from
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.) > By fencing the pointer's validity to a particular scope we can also keep array value semantics safe Sure thing. So does this then mean that the kind of "unsafe/real address-of" operation can't be generally realized? On Fri, Dec 25, 2015 at 9:00 PM, Joe Groff <[email protected]> wrote: > > On Dec 24, 2015, at 12:48 PM, Árpád Goretity via swift-evolution < > [email protected]> 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 > > -- Author of the Sparkling language http://h2co3.org/
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
