[swift-evolution] Enhanced existential types proposal discussion

[Thorsten Seitz]

> Am 23.05.2016 um 18:08 schrieb Austin Zheng <austinzheng at gmail.com>:
> 
>> 
>> I think that *all* methods should be available - at least in principle - with associated types 
>> - replaced by their upper bounds (i.e. Any if no constraints have been given either by the protocol definition itself or th existential) if in covariant position and 
>> - replaced by their lower bounds if in contravariant position
>> 
>> As it is not possible to define lower bounds in Swift, the lower bounds are always the bottom type (called `Nothing` in Swift and not be confused with optionals). The bottom type has no members and therefore a method referencing that type cannot be called and is effectively not available.
>> 
> 
> Thanks for the feedback! So methods that have associated types in contravariant position would have those types be Nothing, unless there was a concrete type bound to that associated type in the Any's where clause?
> 
> Example
> 
> protocol MyProtocol {
>   associatedtype AssocType1
>   associatedtype AssocType2
>   func foo(x: AssocType1, y: AssocType2)
> }
> 
> let a : Any<MyProtocol>
> // on 'a', foo is exposed as 'foo(x: Nothing, y: Nothing)', and can thus not be called
> 
> let b : Any<MyProtocol where .AssocType1 == Int>
> // on 'b', foo is exposed as 'foo(x: Int, y: Nothing)' and still can't be called
> 
> let c : Any<MyProtocol where .AssocType1 == Int, .AssocType2 == String>
> // on 'c', foo is exposed as 'foo(x: Int, y: String)', and can therefore be called
> 
> Let me know if this is what you had in mind.

Yes, that’s what I had in mind. 

IMHO this would make for simple rules and if Swift might one day get the ability to specify lower bounds this would easily fit in (I don’t know how useful that would be in reality, but I think Scala allows the declaration of lower bounds).

-Thorsten

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160523/a101e5d5/attachment.html>