Thanks Slava, Then my memory wasn’t that bad. This is indeed what I was thinking of, but I should not have referred to it as ‘boxing’ ?
Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 19 Jan 2017, at 05:57, Slava Pestov <spes...@apple.com> wrote: > > For what it’s worth, if T is a reference type or Unsafe*Pointer, then T and > Optional<T> have the same exact representation in memory. > > The compiler is smart enough to know that a non-optional pointer can never be > NULL, so a NULL value of the underlying type can be used to unambiguously > encode the ‘none’ case. This is not the case with Optional<NSRect> for > example, where every bit pattern represents a potentially valid NSRect value, > so Optional<NSRect> has to add an extra tag byte to distinguish the two enum > cases from each other. > > Slava > >> On Jan 10, 2017, at 9:52 AM, Rien via swift-users <swift-users@swift.org> >> wrote: >> >> I stand corrected. >> >> I do/did think that there is a difference in the way it handles pointers >> optionals and other optionals, but I now realise that even that could not be >> the case. >> So please ignore the last line in my previous post. >> >> The rest still stand ;-) >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Swiftrien >> Project: http://swiftfire.nl >> >> >> >> >>> On 10 Jan 2017, at 18:14, Joe Groff <jgr...@apple.com> wrote: >>> >>> >>>> On Jan 9, 2017, at 11:19 PM, Rien via swift-users <swift-users@swift.org> >>>> wrote: >>>> >>>> It means that a call to that function with an optional will unwrap the >>>> optional before it is used. >>>> >>>> That is quite neat when dealing with C-API’s because often you will >>>> receive a pointer from a C-function which is optional to account for the >>>> fact that it can be NULL (= nil). >>>> By using a forced unwrapped input parameter you are saved the trouble of >>>> unwrapping all these pointers when using them as input for other C-APIs. >>>> >>>> In short, it makes it easier to interface with C-API’s. >>>> >>>> Note that there is some under-the-hood magic going on because a C-pointer >>>> is an unboxed value, while a ‘normal’ optional is a boxed value. >>> >>> Optionals are never boxed. >>> >>> -Joe >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users > _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
