[swift-evolution] Making pointer nullability explicit (using Optional)

[Jordan Rose]

> On Mar 24, 2016, at 11:02, David Waite <david at alkaline-solutions.com> wrote:
> 
> From "[swift-evolution] Notes from Swift core team 2016-03-23 design discussion”:
>> Make pointer nullability explicit using Optional <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2016-03-23.html#make-pointer-nullability-explicit-using-optional>
>> https://github.com/apple/swift-evolution/pull/219 <https://github.com/apple/swift-evolution/pull/219>
>> Biggest open issue is what to do with UnsafeBufferPointer which has a base address and a count of the number of elements at that address. The most common use is to do fast things with an array. The problem is when you have an empty array.
>> 
>> We have a statically initialized empty array, so this doesn’t apply to array. But slices and Cocoa arrays can do it.
>> 
>> Half of the use cases are subscripting off of the buffer, so they don’t actually use the base address. They can’t actually subscript an empty array, but it’s not a syntax error — the loop is run zero times, so it doesn’t matter. The other half pass the pointers down to a C API that takes an address and count.
>> 
>> Someone might expect that the base address doesn’t change when something is initialized.
>> 
>> We can’t easily use the zero pointer because SIL already uses it for nil. But there are issues with using the same representation as C to avoid bridging costs.
>> 
>> We’re mapping two things in C onto one thing in Swift. In C, the buffer pointer would be __nullable long * and the length is ulong.
>> 
>> Given everything else in the system, it’s more like pointer. We didn’t call it a buffer because that tends to imply ownership.
>> 
>> Sketching out the state space:
>> 
>> Pointer	Length	Static type
>> null	0	UBP?	 
>> valid	>= 0	UBP	 
>> valid	< 0	X	 
>> vull	!= 0	???	 
>> This issue would go away if we got rid of the base address on UnsafeBufferPointer, but that would get rid of a number of valid C operations like calling memcopy.
>> 
>> It seems like withUnsafeBufferPointer should never produce nil. With that in mind, why should UnsafeBufferPointer need to?
>> 
>> We do need a properly-aligned “valid” invalid pointer. LLVM makes assumptions about things being aligned.
>> 
>> Dominant feedback on the list has been for people want something that round trips cleanly. Making the base address non-optional adds overhead and removes the ability to round trip.
>> 
>> It’s unfortunate that we don’t have a way to represent in the type system a buffer pointer that isn’t nullable, from within withUnsafeBufferPointer which wouldn’t even call its closure if the buffer has a null base address.
>> 
> In my mind UBP is primarily meant to be a collection. In that case, I imagine (nil, 0) as an input wouldn’t necessarily represent a nil UBP? - it could represent an empty UBP. 
> 
> My question is whether a valid pointer, length 0 is a valid UBP or not - I have trouble imagining a API which wants a UBP which would differentiate this value over the (nil, 0) one and not have it either be an abuse of UBP (using it to transport just a pointer and not representing a buffer) or an error. I suspect it actually would be ok to always represent a length 0 UBP as having a nil base address.

I updated the proposal before it got accepted into the queue; the consensus was for the "round-trips cleanly" case. A (valid, 0) pair could still represent a range to replace in a C API, so canonicalizing to nil might be a bad idea.

You can see the current version here as SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md <https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md>

Jordan

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