> On Mar 24, 2016, at 11:02, David Waite <da...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
