[swift-evolution] Generic types―covariance/contravariance

[Hooman Mehr]

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.

> On Dec 9, 2016, at 10:41 AM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I keep seeing collections brought up whenever this is discussed, so my question is: Have you found a broader use for variance annotations in the Swift you write?  Even in Objective-C (perhaps due to their relative obscurity) I don't see (non-Foundation) people make use of the variance annotations for generic classes, so it makes me think we could just implement this as an extension to the collection casting machinery instead of exposing a Scala-esque variance notation.  Sort of like how it was done before when subtyping was introduced for function types around 2.x IIRC.
> 
> ~Robert Widmann
> 
> 2016/12/08 19:45、Braeden Profile via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
> 
>> Has the core team or the community considered the possibility of implementing covariant/contravariant generic types?  It would really be appreciated.
>> 
>> I know with Array, vague-ifying or specific-ifying the type ([Int] to [Any]) has help from the compiler—and we can use `map` if all else fails—but that only lessens the impact of the missing functionality.  This is my exact use case here, using SceneKit to identify the first-hit Controller object:
>> 
>> class ControllerNode<Controller: AnyObject>: SCNNode
>> {
>> 	let controller: Controller
>> }
>> 
>> // Ordered front to back, returns the first Controller object.
>> for hit in hitTest
>> {
>> 	// Determine if this node is part of a controller.
>> 	let ancestrySequence = sequence(first: hit.node, next: { $0.parent })
>> 	let lastControllerNode: ControllerNode<AnyObject>? = ancestrySequence.reduce(nil)
>> 		{ ($1 as? ControllerNode) ?? $0 }
>> 	
>> 	if let cabinet = lastControllerNode?.controller as? CabinetController
>> 		{ return cabinet }
>> 	
>> 	if let wall = lastControllerNode?.controller as? WallController
>> 		{ return wall }
>> }
>> 
>> This compiles, but unfortunately, this will never work.  The `reduce` algorithm always ends up trying to convert things like `ControllerNode<WallController> as ControllerNode<AnyObject>`, which—unintuitively—always fails.  Without compiler help, so would things like `myIntArray as [Any]` or `Optional<Boy>(Boy()) as Optional<Human>`.
>> 
>> If Swift is supposed to welcome generic programming, this would be a great thing to have.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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