[swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

[Антон Жилин]

UnsafeBufferPointer is currently represented as a (nullable) C pointer plus
size. It can be implemented almost in pure Swift (with calls to C
functions).

After the proposal is accepted, it will be replaced with
Optional<UnsafeBufferPointer>. But it will require a compiler-only "hack"
for Optional not to require extra memory for nil (I assume, Optional will
look into address part of UnsafeBufferPointer). This symbiosis will have to
be built in the compiler, and I call that "compiler magic".

The need for such magic is an argument for unified UnsafeBufferPointer to
be more "natural". I'm not going to say that this argument will seem strong
for everyone, though.

For that last statement, I was trying to say that we wouldn't need to
invent special value for "empty" UnsafeBufferPointer if we left everything
as it is now.

Also I agree that this change will be positive for use of *Pointer strictly
inside Swift. It is mainly interaction with C that will become more verbose.

2016-03-28 20:45 GMT+03:00 Jordan Rose <jordan_rose at apple.com>:

>
> On Mar 26, 2016, at 9:15, Антон Жилин via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> But we currently have a terser form, and it's arguably clear from it that
> Pointer can be null.
>
>
> For the record, I literally talked to someone last week who didn't know
> that UnsafePointer can be null. :-) They thought we'd already implemented
> this and there was a bug in the importer.
>
> Overall, separating strongly connected concepts and then tying them
> together using compiler magic just can't have a reasonable explanation.
> ~0x0 in UnsafeBufferPointer is utterly rediculous.
>
>
> I'm not sure what this comment refers to. Can you explain?
>
> Jordan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160328/0d4e7502/attachment.html>