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 > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> のメッセージ: > >> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
