Sent from my iPad
> On Feb 15, 2017, at 8:17 PM, Jordan Rose <[email protected]> wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> <[email protected]> wrote: >>> >>> >>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution >>> <[email protected]> wrote: >>> >>> Having loosely followed this discussion, the way I'm thinking of ‘closed’ >>> is as a modifier which would let you switch over something from outside the >>> module in which it is declared. >>> >>> From outside the declaring module: >>> • A closed enum's cases can be exhaustively switched. >>> • A closed protocol's conforming types can be exhaustively switched. >>> • A closed class's subclasses can be exhaustively switched. >>> >>> If this is correct, I can't help but think ‘closed’ is describing something >>> subtly different in each case - picking and choosing the ‘important’ >>> relationship for each type, while protocols already have a subtyping >>> relationship, and it sounds like there's possibility for enum subtyping in >>> the future. >>> >>> I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing >>> the subtyping relationship, and have some other means of labelling >>> conformance and cases as switchable. >> >> I am drafting a manifesto-style document regarding value subtyping which >> will make it clear how value subtypes fit into the picture. This document >> covers the relationship of enum cases with value subtyping and will show >> clearly how enum cases are analogous to subclasses. > > I'm not sure how it fits your document, but I suspect value subtyping is > pretty much not at all a source-compatibility or binary-compatibility > concern. I think the only reasonable implementation here would be to perform > conversions (unidirectional or bidirectional?), I meant to reply to this in my last message. Yes, the only sensible implementation I can think of is via conversion, which may be possible to optimize away in some cases where the supertype is representationally compatible with the subtype. Bidirectional conversion / inout wouldn't make sense. If you allow the supertype to mutate you may end up with a value that is not representable by the subtype. > which means that the subtyping is almost entirely a client-side feature and > the only potential dynamic operation would be using 'as?' with a generic > type. This is very different from protocols and classes, which perform > dynamic dispatch to method implementations present on their subtypes. > > That is, the only effect of making a type "non-open" with respect to value > subtyping would be to cut down on potential costs of 'as?'. > > Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
