Hi Thomas,
I see what you mean now. I think in this case I would prefer to just spell this
as ‘switch x { … unknown: … }’ vs ‘switch x { … default: … }’. But yes, a few
people have signaled support for such a feature and I think it’s worth
discussing.
Slava
> On Dec 23, 2017, at 4:27 PM, Thomas Roughton <[email protected]> wrote:
>
> Hi Slava,
>
> I think we may be referring to different things. For whatever it’s worth, I
> agree with your reasoning on all the points you brought up. I also don’t
> think having a 'default: fatalError()’ case is a good idea because then a
> library change can cause crashes in a running version of an application.
>
> What I mean by some sort of ‘complete switch’ statement is that it would be
> compiled as per a normal ‘switch’ but error at compile time if it’s not
> complete against the known set of cases as compile time. Assuming an enum
> with known cases [a, b] at compile time,
>
> switch nonExhaustiveEnum {
> case a:
> print(“a”)
> case b:
> print(“b”)
> default:
> break
> }
>
> would be exactly equivalent to:
>
> complete switch nonExhaustiveEnum {
> case a:
> print(“a”)
> case b:
> print(“b”)
> unknown: // the ‘unknown’ case would only be required for
> non-exhaustive enums
> break
> }
>
> where the keywords ‘complete’ and ‘unknown’ are up for debate. If, however,
> the programmer wrote:
>
> complete switch nonExhaustiveEnum {
> case a:
> print(“a”)
> unknown:
> break
> }
>
> the compiler would give an error that there are unhandled cases in the switch
> statement, whereas
>
> switch nonExhaustiveEnum {
> case a:
> print(“a”)
> default:
> break
> }
>
> would compile without issue. If a user didn’t know about the existence of the
> ‘complete switch’ construct, they could just use normal ‘switch’ statements
> and miss out on the completeness checking.
>
> Thomas
>
>> On 24/12/2017, at 1:15 PM, Slava Pestov <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>>> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>>>> [email protected] <mailto:[email protected]>
>>>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
