> On Jan 11, 2018, at 05:08, Michel Fortin <michel.for...@michelf.ca> wrote:
> 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.

I’m not sure I’d agree that most people would think of private cases are 
“undeclared”, but sure, it’s a reasonable alternative. I still like “unknown” a 
little better myself.


>> Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>> On Jan 10, 2018, at 10:10 AM, Jordan Rose <jordan_r...@apple.com 
>>> <mailto:jordan_r...@apple.com>> 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
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> -- 
> Michel Fortin
> https://michelf.ca <https://michelf.ca/>

swift-evolution mailing list

Reply via email to