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

Reply via email to