[swift-evolution] Generic types―covariance/contravariance

David Waite david at alkaline-solutions.com
Sat Dec 10 10:18:55 CST 2016


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> 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/69d6fb3b/attachment.html>


More information about the swift-evolution mailing list