Thank you for elaborating on your concerns! Some responses below.
> On Mar 28, 2016, at 11:09, Антон Жилин <antonyzhi...@gmail.com> wrote:
>
> 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>.
That is not the proposal; please re-read the section on UnsafeBufferPointer.
<https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md#unsafebufferpointer>
(You might not be happy with this version either, though.)
> 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".
This is actually standard behavior for all enum types (guaranteed) and all
struct types whose first property is such an enum or built-in type with
available "extra inhabitants" (an optimization whose details may change in the
future). This includes structs beginning with a non-optional AnyObject, and
enum types you define like this:
enum Maybe<T> {
case just(T)
case nothing
}
If 'T' is a type that has a known invalid representation, such as AnyObject,
that representation will be used for the 'nothing' case of 'Maybe<T>'
Best,
Jordan_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
