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

[Michel Fortin]

> Le 17 mars 2016 à 21:59, Jordan Rose via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>  <https://github.com/jrose-apple/swift-evolution/tree/optional-pointers#open-issue-unsafebufferpointer>Open Issue: UnsafeBufferPointer
> 
> The type UnsafeBufferPointer represents a bounded typed memory region with no ownership or lifetime semantics; it is logically a bare typed pointer (its baseAddress) and a length (count). For a buffer with 0 elements, however, there's no need to provide the address of allocated memory, since it can't be read from. Previously this case would be represented as a nil base address and a count of 0.
> 
> With optional pointers, this now imposes a cost on clients that want to access the base address: they need to consider the nil case explicitly, where previously they wouldn't have had to. There are several possibilities here, each with their own possible implementations:
> 
> Like UnsafePointer, UnsafeBufferPointer should always have a valid base address, even when the count is 0. An UnsafeBufferPointer with a potentially-nil base address should be optional.
> 
> UnsafeBufferPointer's initializer accepts an optional pointer and becomes failable, returning nil if the input pointer is nil.
> 
> UnsafeBufferPointer's initializer accepts an optional pointer and synthesizes a non-null aligned pointer value if given nil as a base address.
> 
> UnsafeBufferPointer's initializer only accepts non-optional pointers. Clients such as withUnsafeBufferPointermust synthesize a non-null aligned pointer value if they do not have a valid pointer to provide.
> 
> UnsafeBufferPointer's initializer only accepts non-optional pointers. Clients using withUnsafeBufferPointermust handle a nil buffer.
> 
> UnsafeBufferPointer should allow nil base addresses, i.e. the baseAddress property will be optional. Clients will need to handle this case explicitly.
> 
> UnsafeBufferPointer's initializer accepts an optional pointer, but no other changes are made.
> 
> UnsafeBufferPointer's initializer accepts an optional pointer. Additionally, any buffers initialized with a count of 0 will be canonicalized to having a base address of nil.
> 
> I'm currently leaning towards option (2i). Clients that expect a pointer and length probably shouldn't require the pointer to be non-null, but if they do then perhaps there's a reason for it. It's also the least work.
> 
> Chris (Lattner) is leaning towards option (1ii), which treats UnsafeBufferPointer similar to UnsafePointer while not penalizing the common case of withUnsafeBufferPointer.

`baseAddress` not returning the same value as was passed in the constructor seems bizarre to me. Surprising semantics is probably not what we should have in code that deals with unsafe pointers. That's why I feel like (2i) is the best solution.

My interpretation is that what Chris (Lattner) likes with (1ii) is a value that traps when `nil` but does not require explicit checking for `nil`. To me that sounds like an implicitly-unwrapped optional. Maybe we could have (2i) but with an IUO for `baseAddress`. That'd be much cleaner than silently replacing `nil` with an arbitrary non-nil underefrencable address.

-- 
Michel Fortin
https://michelf.ca

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