I think `unknown` should be a modifier for either `case` or `default`. This
would allow:
unknown default:
unknown case _: // similar to default
unknown case (1, _): // enum in second position
If the case can be reached with statically known enum values, the compiler
generates a warning.
I'd also prefer a more precise term instead of "unknown". What we aim at is
matching cases that do not have a declaration (future cases, privately-declared
cases). So I'd use the word "undeclared" rather than "unknown":
undeclared default:
undeclared case _: // similar to default
undeclared case (1, _): // enum in second position
That word has the advantage that enums are also less likely to have a case
named "undeclared", I think.
> Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution
> <[email protected]> a écrit :
>
>
>> On Jan 10, 2018, at 10:10 AM, Jordan Rose <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>>
>>>> - Matching known cases is a feature, not a limitation, to avoid existing
>>>> code changing meaning when you recompile. I'll admit that's not the
>>>> strongest motivation, though, since other things can change the meaning of
>>>> existing code when you recompile already.
>>>
>>> I’m not sure I understand this.
>>>
>>> The whole motivation for this feature is to notify people if they are not
>>> handling a “newly known” case. If they don’t care about this, they can
>>> just use default.
>>
>> Notify, yes. Error, no. It's a design goal that adding a new case does not
>> break source compatibility in addition to not breaking binary compatibility
>> (because people don't like editing their dependencies) and therefore the
>> behavior has to be defined when they recompile with no changes.
>>
>
> Ok, if that’s the desired design, then (IMO) the right way to spell it is
> “unknown default:” and it should have semantics basically aligned with the
> design you laid out in the revision of the proposal. If this is supposed to
> be an error, then it should be a pattern production.
>
> Do you have a sense for whether this is what people want? We really should
> have a review cycle evaluating exactly this sort of tradeoff.
>
> In any case, I’ve said this before off-list, but I find this whole discussion
> (of how to improve diagnostics for unknown cases) to be separable from the
> core issue required to get to ABI stability. It seems to me that we could
> split this (ongoing) design discussion off into a separate SE, allowing you
> to get on with the relatively uncontroversial and critical parts in SE-0192.
>
> -Chris
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Michel Fortin
https://michelf.ca
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
