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

[David Waite]

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.

Alternatively expressing the way I see it in mock data structures:

enum InnerUnsafeBufferPointerRepresentation<T>  {
   case empty
   case some(UnsafePointer<T>, Int) // where Int is always > 0
}

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160324/efb5d9f2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160324/efb5d9f2/attachment.sig>