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

[Árpád Goretity]

> 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 <jgroff at apple.com> wrote:

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


-- 
Author of the Sparkling language
http://h2co3.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151225/0495c7f9/attachment.html>