[swift-evolution] Generic types―covariance/contravariance

[Hooman Mehr]

As Braeden notes, the same compiler magic already works for most standard library container / monadic types. It could probably work in more cases. 
Let me clarify what I meant:

This compiler magic is a very useful machinery that already exists and although the use cases are not wide enough to “pollute” the whole language, they are important enough to warrant making this compiler machinery public and usable by other framework authors besides the standard library.

> On Dec 10, 2016, at 8:18 AM, David Waite <david at alkaline-solutions.com> wrote:
> 
> I wouldn’t keep it that narrow - monadic types like Optional also benefit from variance:
> 
> func p(_ data:Any?) { 
>   if data != nil { 
>     data.map { print($0) }
>   } 
> } 
> var a:String? = "foo"
> p(a)
> // -> “foo"
> 
> 
> -DW
> 
>> On Dec 9, 2016, at 12:24 PM, Hooman Mehr via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> For the specific case of custom collections, I think it is worth providing a protocol as Doug noted before.
>> 
>> Quoting Doug Gregor (1/13/16, thread: "Make generics covariant and add generics to protocols”): 
>>> Swift’s value-semantic collections are covariant in their generic parameters, which we do through some fairly tight coupling between the compiler and standard library. From a theoretical standpoint, I’m very happy with the way value-semantic collections provide subtyping and mutation while maintaining soundness (== no runtime checks needed), and for me I would consider it “enough” if we were to formalize that compiler/collection type interaction with some kind of protocol so other collection types could opt in to subtyping, because I don’t think variance—as a language feature—carries its weight outside of the fairly narrow collection-subtyping cases.
>> (Emphasis mine) 
>> 
>> I also agree with Doug and you that variance does not carry its weight outside of collection-subtyping cases.
> 
> -DW

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