[swift-users] Existentials in Swift

[Karl Wagner]

1. Yes
 
2. Yes
 
3. I don't know the actual reason, but Any and AnyObject have special meaning to the compiler and objects implicitly "conform"" to them. Either the implementation doesn't support extending those types, or we explicitly decided that extending these implicit existentials was a bad idea (what could you even write in an extension in Any? You'd almost certainly have to cast it to Something. Extend Something instead.)
 
 - Karl
   
 
 
 

 
 
 
 

 
 
>  
> On Nov 21, 2016 at 11:09 am,  <Toni Suter via swift-users (mailto:swift-users at swift.org)>  wrote:
>  
>  
>   Hi everyone, 
>
>  
> I am trying to understand existentials in Swift. I understand that in the
>  
> following code, P1  &  P2 is an existential type, because it supports values
>  
> from all types that conform to both P1 and P2.  
>  
>
>  
> protocol P1 {}
>  
> protocol P2 {}
>  
> var x: P1  &  P2
>  
>
>  
> However, this raises a few questions for me:
>  
>
>  
> 1. In the following code, is x also an existential?
>  
> protocol P {}
>  
> var x: P
>  
>
>  
> The proposals / blog posts that I read always talk about the protocol composition syntax,
>  
> but to me, this is the same as the first example, just with only a single protocol requirement.
>  
>
>  
> 2. Are Any and AnyObject also existentials?
>  
> So far, my understanding is:
>  
> Any is an existential with no requirements
>  
> AnyObject is an existential with only a class requirement
>  
>
>  
> 3. Why can I not extend Any / AnyObject?
>  
> For example, AnyObject is a protocol defined in the standard library. Why is it not extensible?
>  
>
>  
> Thanks and best regards,
>  
> Toni
>  _______________________________________________ swift-users mailing list  swift-users at swift.org (mailto:swift-users at swift.org)   https://lists.swift.org/mailman/listinfo/swift-users
>  
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161121/9728f685/attachment.html>