[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