Boxing usually refers to out-of-line allocation of values on the heap. For example, values of protocol type (as well as Any) will box their payload, depending on size.
Slava > On Jan 18, 2017, at 10:53 PM, Rien <r...@balancingrock.nl> wrote: > > 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
