A question about the new #unknown behavior. Is it intended to be used for error
handling too ?
Will it be possible to use in catch clause ?
> Le 12 janv. 2018 à 02:48, Howard Lovatt via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> Well if you are happy to say removal of a case isn’t allowed, why not be
> symmetrical and say adding isn’t allowed and if an API would like to add
> cases then it needs to do so via adding an extended enum, e.g.:
>
> enum Old {
> case old1, old2
> }
> enum New {
> case old1 // Note missing old2.
> case new1
> }
> struct Ex {
> func f(old: Old) -> Old { ... }
> func f(new: New) -> New { ... }
> }
>
> If this approach is taken then it is more work for Apple and less work for
> developers and a cleaner Swift. So overall it might be the best approach.
>
> -- Howard.
>
> On 11 Jan 2018, at 11:23 am, Jordan Rose via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>>
>>
>>> On Jan 11, 2018, at 05:08, Michel Fortin <michel.for...@michelf.ca
>>> <mailto: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.
>>
>> Jordan
>>
>>
>>>
>>>> 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
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>>
>>>
>>> --
>>> Michel Fortin
>>> https://michelf.ca <https://michelf.ca/>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
