> On Dec 23, 2017, at 4:15 PM, Slava Pestov via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
>> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>>> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>> What are your thoughts on `final switch` as a way to treat any enum as
>>> exhaustible?
>>> https://dlang.org/spec/statement.html#FinalSwitchStatement
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> I’d be very much in favour of this (qualms about the naming of the ‘final’
>> keyword aside - ‘complete’ or ‘exhaustive’ reads better to me).
>>
>> Looking back at the proposal, I noticed that something similar was mentioned
>> that I earlier missed. In the proposal, it says:
>>
>>> However, this results in some of your code being impossible to test, since
>>> you can't write a test that passes an unknown value to this switch.
>>
>> Is that strictly true? Would it be theoretically possible for the compiler
>> to emit or make accessible a special ‘test’ case for non-exhaustive enums
>> that can only be used in test modules or e.g. by a
>> ‘EnumName(testCaseNamed:)’, constructor? There is potential for abuse there
>> but it would address that particular issue.
>>
>> Regardless, I still feel something like a ‘final switch’ is necessary if
>> this proposal is introduced, and that it fits with the ‘progressive
>> disclosure’ notion; once you learn this keyword you have a means to check
>> for completeness, but people unaware of it could just use a ‘default’ case
>> as per usual and not be concerned with exhaustiveness checking.
>
> My general philosophy with syntax sugar is that it should do more than just
> remove a constant number of tokens. Basically you’re saying that
>
> final switch x {}
>
> just expands to
>
> switch x { // edited
> default: fatalError()
> }
>
> I don’t think a language construct like this carries its weight.
Having the ability to treat a non exhaustive enum as if it where exhaustive is
not the same as
switch x {
default : fatalError()
}
The above will happily let me omit currently compile time known cases. Perhaps
‘final switch’ is not the best but I can’t think of another way to semantically
“cast” a non exhaustive as exhaustive. Essentially what I believe we want is a
way to treat a non exhaustive as exhaustive during compile time, on the client
side.
It would be cool if we instead repurposed the swift “case _” to handle all
compile time known cases and default could then handle all unknown future cases
in an non exhaustive enum.
public enum x {a, b, c, d}
switch x { // x is non exhaustive here
case a: print("case a")
case _ : print(“known cases b c or d”) // sugar for cases b, c, d which are
known during compile time. Expanded to mean case b, c, d.
default: fatalError() // future unknown cases
}
I don’t think this would would break any code since all enums have been
exhaustive. No new syntax would be added and now there would be a meaningful
difference between compile time known cases (case _) vs compile time unknown
future cases (default).
>
> For example, generics have a multiplicative effect on code size — they
> prevent you from having to write an arbitrary number of versions of the same
> algorithm for different concrete types.
>
> Another example is optionals — while optionals don’t necessarily make code
> shorter, they make it more understandable, and having optionals in the
> language rules out entire classes of errors at compile time.
>
> On the other hand, a language feature that just reduces the number of tokens
> without any second-order effects makes code harder to read, the language
> harder to learn, and the compiler buggier and harder to maintain without much
> benefit. So I think for the long term health of the language we should avoid
> ‘shortcuts’ like this.
>
> Slava
> _______________________________________________
> 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
