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

> On Dec 25, 2015, at 12:29 PM, Árpád Goretity 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

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

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

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

> On Dec 24, 2015, at 12:48 PM, Árpád Goretity via swift-evolution > 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).

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

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

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

> On Dec 23, 2015, at 5:35 PM, Árpád Goretity via swift-evolution > wrote: > > Hi everyone, > > I was recently trying to use a C API (LLVM for the record) that required > passing an array to a function in the form of a pointer and a size. I > couldn't find a

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

The & operator isn't exactly an address-of operator. Does [0] even return a pointer to the inner buffer? When you use & with properties (and possibly with subscripts as well), Swift may create a local, copy the property value to it, pass a pointer to that local, and copy back the output to the

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

> On Dec 23, 2015, at 5:50 PM, Félix Cloutier via swift-evolution > wrote: > > The & operator isn't exactly an address-of operator. Does [0] even return > a pointer to the inner buffer? When you use & with properties (and possibly > with subscripts as well), Swift

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

> The comments in the generated header for UnsafeMutablePointer claim that its regular init() method constructs a null pointer. That's right, and I have tried it as well. Yet, type inference doesn't like like it, and I get back an error similar to what I have already described, but this time with

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

> On Dec 23, 2015, at 7:50 PM, Félix Cloutier via swift-evolution > wrote: > > The & operator isn't exactly an address-of operator. Does [0] even return > a pointer to the inner buffer? When you use & with properties (and possibly > with subscripts as well), Swift