>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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
