On Jan 9, 2018, at 12:27 PM, Vladimir.S <sva...@gmail.com> wrote:
>> 2) Swift also has other facilities for pattern matching, including ‘if
>> case’. Making switch inconsistent with them is not great.
>> 3) As pitched, “unknown case” will match *known* cases too, which is (in my
>> opinion :-) oxymoronic.
>
> Are you saying here about situation, when new case is added in non-frozen
> enum, but we are compiling the old code with absent new case but with
> "unknown case" in switch? As stated in proposal, in this case we'll have a
> warning exactly for source compatibility reason: "..unknown case matches any
> value. ... the compiler will produce a warning if all known elements of the
> enum have not already been matched. This is a warning rather than an error so
> that adding new elements to the enum remains a source-compatible change." Do
> you suggest to change that warning into error?
>
> Or you are saying about another situation when “unknown case” will match
> known cases too in the initial proposal ?
In the proposal, ‘unknown case’ is a synonym for default with changes to
warning generation. This means that it matches everything, including cases
known at static compile time.
>> 4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier
>> on case) because case *requires* a pattern. A better spelling would be
>> “unknown default:” which is closer to the semantic provided anyway.
>> 5) It is entirely reasonable (though rare in practice) to want to handle
>> default and unknown cases in the same switch.
>
> Are you suggesting to have this?:
>
> switch val {
> case .one: ...
> case .two: ...
> case #unknown: ...
> default: ..
> }
Yes.
> So, all new cases, introduced in external module after compilation of that
> code will fall into "case #unknown: ..." bucket, but all "known"(at the
> moment of compilation) cases but not .one/.two - into "default:..." ?
> Personally I like that, so if I need this - I will be able to express this,
> but that rule seems like complicated to understand.
> But this can be really helpful in situation, when you *at compilation time"
> thinks that you are not interested in anything but .one/.two cases of that
> enum, but in case of new values - you want to show(for example) a warning for
> app user.
Exactly. It is a narrow case, but it is important to me that we provide
primitives that compose properly.
>
> Do I understand correctly, that you suggest the same behavior as in
> original(updated) proposal:
> * if we have a switch on non-frozen enum value, and enumerated some cases,
> and have "case #unknown" - we'll have a warning(error?) if (at the moment of
> compilation) not all known enums are processed in "switch” ?
Yes.
> Just to be sure.
>
> Btw, should this be valid? :
> switch val {
> case #unknown:... // I'm only interested if new values were added to that
> external enum
> default: ... // as I understand, "default" will be required here
> }
Yes, this would be very weird to write, but would be valid: the default matches
all known cases at compile time. I’d suggest that you write that as a “if case
#unknown” with an else though.
-Chris_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
