> 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 <mailto: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
>> <https://dlang.org/spec/statement.html#FinalSwitchStatement>_______________________________________________
>> 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>
>
> 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
swift x {
default: fatalError()
}
I don’t think a language construct like this carries its weight.
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
