[swift-evolution] Proposal: One-past-end array pointers and convertibility of nil for interaction with C APIs
jgroff at apple.com
Sat Dec 26 17:05:33 CST 2015
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution