[swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

[Thorsten Seitz]

Hi all,

I am very much in favor of ‘switch x { … unknown: … }’ to express that I am expecting the cases to be complete at compile time so that I get notified when compiling against a newer version of the library where the enum has been extended.

I consider not being able to test this a minor problem compared with not getting informed when new cases have been added. 

-Thorsten


> Am 24.12.2017 um 01:29 schrieb Slava Pestov via swift-evolution <swift-evolution at swift.org>:
> 
> 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 <t.roughton at me.com <mailto:t.roughton at me.com>> 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 <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171227/03a61917/attachment.html>