> On Aug 11, 2017, at 02:59, Vladimir.S <[email protected]> wrote:
>
> On 11.08.2017 2:37, Jordan Rose wrote:
>> Both you and Vladimir are bringing up this point, with Vladimir explicitly
>> suggesting a "future" case that's different from "default". Again, the
>> pushback we get here is that the "future" case is untestable…but maybe
>> that's still an option worth having.
>
> I wonder, how the 'default' in exhaustive switch on open enum is testable?
>
> I mean, let's say we have such enum in one of the frameworks:
>
> open enum MyOpenEnum {
> case one
> case two
> }
>
> , then in our code:
>
> switch myOpenEnumInstance {
> case .one : ...
> case .two : ...
> default : ... // how this can be tested?
> }
>
> I just strongly feel that be able to keep switch exhaustive at the moment of
> compilation - is critical requirement in some cases, when it is very
> important to not forget to process some cases. With just 'default' in switch
> for open enum - we are loosing this compiler's help. This is why 'future'
> case is required for open enums.
>
> Also, if I understand correctly, we are going to have most of all
> extern(imported) enums as 'open'. So, we are loosing the feature to receive a
> help for exhaustive switch from compiler for most of such enums.
That's true, but I don't know what to do about it. My hypothesis, again, is
that this won't be common in practice; so far Charlie's been the only one to
provide a real-world example of when this is useful.
> Moreover, shouldn't we just say that enums, that we have no Swift sources for
> at the moment of compilation - should *always* be treated as 'open'? If we
> compile our 'switch' together with the source of switched enum - such enum
> can not be changed in the future.
> But, if enum is coming from other framework - we have no any control over it,
> and even author of framework IMO can't be sure in most cases that enum will
> not be extended in future, and probably we even should not ask author of
> framework to consider its enum closed, as most likely one can't foresee for
> sure.
>
> Wouldn't this be a simpler and more robust model to think about enums in
> Swift?
> So you know, that *any* enum coming from framework(not from source) - can be
> changed in future, and so you have to process this case explicitly. In this
> case we don't need to mark enum as 'open' or 'closed' at all, but for some
> rare cases, when author of framework *really sure* enum can not be changed in
> future(and future change in enum will break all the code depending on it), we
> can introduce some 'final' marker(or @exhaustive directive) to help
> compiler's optimizations.
Again, some enums really do want to be exhaustive: Foundation.ComparisonResult,
Swift.Optional, and in general anything the framework owner really does want
people to exhaustively switch over. These aren't just optimization concerns
because they affect how people are expected to use the type. I think this all
just means that you're on the side that "open" should be the default.
>
> Btw, is open enum is allowed to change the type of associated value for some
> cases or even enum's raw type? I.e. what changes in open enum will lead to
> crash in our code and which will just be processed in 'default'/'future'
> block in switch?
Nope, that's not planned to be allowed. That would break source compatibility
outside of just switch—it would also affect `if case` as well as the creation
of an enum with that case.
The last time I thought about this, I came up with this list of things we want
to allow in "open" enums:
• Adding a new case.
• Reordering existing cases is a "binary-compatible source-breaking
change". In particular, if an enum is RawRepresentable, changing the raw
representations of cases may break existing clients who use them for
serialization.
• Adding a raw type to an enum that does not have one.
• Removing a non-public, non-versioned case (if we ever have such a
thing).
• Adding any other members.
• Removing any non-public, non-versioned members.
• Adding a new protocol conformance (with proper annotations).
• Removing conformances to non-public protocols.
We're now questioning whether reordering should be allowed at all for
implementation reasons, but other than that this list should still be accurate.
>
> Vladimir. (P.S. Sorry for long reply)
Thanks for thinking about this in detail; better to get the problems out in the
open now before I write up a formal proposal!
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
