On 12.08.2017 1:37, Jordan Rose wrote:
On Aug 11, 2017, at 02:59, Vladimir.S <[email protected] <mailto:[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.
So, do you want to say that we usually will not have open enums which we want to
switch exhaustive? Probably I can't understand exactly this point.
Seems like you are saying about enums in Foundation/SDK, while I'm thinking about any
given framework/module, including compiled from 100% Swift code, even made by
me/colleague.
It will be very interesting to check the number of exhaustive switches in open source
Swift projects regarding enums imported from other frameworks. So, this can tell us
if developers often/rarely decided to check each case in external enum, declared in
some framework. Probably someone have such information?
My request for 'future' block in switch for open enum based on belief that it can be
also my(as framework's user) decision if *I* want to keep the switch exhaustive in my
code in some situation. Framework's author just can't foresee all the possible
situations and requirements of my code. For some reason I still can't accept that
this should be just decision of framework's author.
I do expect that the lack of 'future' block for open enums decrease the quality of
Swift code in framework user's code as keep the switch exhaustive will be hard thing
without compiler's help.
"Cases could be added in this open enum in future" and "I, as a framework author,
prevents you from having comiller's help to keep switch exhaustive on this enum"
should not be the same things.
Thinking further, given source compatibility requirement, can we require a change in
consumer's code (in exhaustive switches) by changing what 'public enum {..}' means?
I mean, currently public enum is treated as 'closed', so you have to be exhaustive or
have 'default' block. If we make 'usual' declaration of public enum means 'open' -
we'll break some consumer's code - as starting from this point they have to contain
'default'/'future' block in exhaustive switch for the same enum declaration.
So, probably, because of this, current 'usual' declaration of public enum should
means 'closed' enum, just like now. So, all *current* code will just compile. And
this will provide a space for optimizations for public enums declared with current
syntax.
Then, in this case, for open enums we need a special marker.
FWIW Right now I see only 3 good candidates:
1. 'open enum'
2. 'public(future) enum'
3. 'public enum MyEnum {case..; case..; future}'
All have pros and cons, while (2) is more explicit and less confusing for me.
But then I was thinking about the Error enums. Most likely it will contain more cases
in future releases, but by mistake framework's developer exported it without 'open'
marker, so any new cases will lead to crash in consumer's code.
What if we consider such solution:
* by default 'public enum' means 'closed' enum and we fully support the source
compatibility requirement
* Swift generates a warning for such enum, something like "Published enum will be
'closed', but you should consider if you really want this as new cases will crash
consumer's code. Please use ... to explicitly express your intention"
* developer then can think and decide what is a 'kind' of this enum and use some
explicit marker to silence the warning and to express intention. For example:
* 'public(closed)'(or 'public(final)' or 'public(sealed)') for 'closed' enums, and
'public(future)' for 'open' enums
OR
* public enum MyError: Error { case..; case..; final} (for closed) and
public enum MyError: Error { case..; case..; future} (for open)
* 'switch' for open enum should contains 'default' or 'future' block. In case of
'future' block, such switch must me exhaustive at the moment of _compilation_.
IMO clear intention and thoughtful decision regarding published enum worth some
additional syntax for *public* enums.
Yes, alternative strategy could be make 'usual' declaration of public enum means
'open' and mark only 'closed' enums with some marker. So, "by default" framework's
author can be free to append new cases in enums without breaking user's code
written/compiled with older version of framework.
BUT this leads to breaking changes in current user's code(have to append
'default'/'future' in exhaustive switches) and in case we will not have 'future'
block - developers will lose current quality of compiler's support.
In case we can introduce such change, and in case we'll have 'future' block in switch
- I(FWIW) believe this also will be good solution, easy to understand but flexible,
which keeps current guarantees of compiler's help.
I hope the text above makes any sense :-)
Vladimir.
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
