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

[Joe Groff]

> On Dec 25, 2015, at 12:29 PM, Árpád Goretity <arpad.goretity at gmail.com> wrote:
> 
> > 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.)

The default NS/CFArray implementation does provide internal interfaces to get at its buffer which we take advantage of. In general, though, an NSArray subclass doesn't need to offer anything more than `objectAtIndex:` and `count`, so we have to be able to deal with a potentially fully opaque interface.

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


It might be possible, but the interactions between pointer-level and high-level accesses would get pretty complex. After a certain point of pointer and lifetime complexity, the high level semantics are just getting in your way IMO, and malloc/free start to be more appealing.

-Joe

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