[swift-evolution] Enhanced existential types proposal discussion

Austin Zheng austinzheng at gmail.com
Mon May 23 13:35:05 CDT 2016

Yes, this is probably better founded.

Right now Swift doesn't have a blessed nothing type, the closest you can
get is enum Nothing { }, and that type doesn't participate in subtyping
relationships (it's not really a Bottom type like Scala's). Proposing such
an expansion to the type system is beyond the scope of this proposal,
although the "associated types" section should certainly be written such
that generalizing it would be trivial if Swift did get contravariant types
and a Bottom type.


On Mon, May 23, 2016 at 11:24 AM, Thorsten Seitz <tseitz42 at icloud.com>

> 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/636a7038/attachment.html>

More information about the swift-evolution mailing list