[swift-evolution] [Pitch] Can we make `default` on switches optional?

[Haravikk]

> On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I think I agree with you. The postfix `!` operator is always shorthand for `fatalError()` (and some more syntax), and it would fit nicely with `default: fatalError()`.
> 
> The Swift usage of `?` is indeed different than `default: break` would do, so `switch?` wouldn’t convey the right message. I hadn’t given it enough thought. I still think a shorthand for `default: break` would be _nice_, but it surely shouldn’t change the `?` consistency, it also shouldn’t replace the current `switch` (as exhaustiveness is very useful) and it’s probably not worth introducing new syntax for.
> 
>> On 4 Oct 2016, at 16:36, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> There is a plausible argument for `switch!`, because it is not possible for the compiler to prove exhaustiveness in all circumstances where you might know it to be the case.
>> 
>> However, I'd be very against `switch?`: it undermines the exhaustiveness guarantee of the switch statement and is wholly inconsistent with Swift usage of `?`, which indicates the possibility of an Optional. We simply don't need a new spelling for `default: break`.

I agree with Tim; I'm a +1 for switch! for a convenient means of erroring out, but I think switch? is a bit too different from normal usage of the question-mark.

One other alternative might be if there could be some kind of switch else syntax, kind of like a guard statement, allowing options on what to do? Only problem is how best to structure it, as the use of break might confusing as to its scope, like so:

	switch(foo) else break { // Break from the switch, or the enclosing block?

So I'm not 100% on that. But it would mean that switch! would be a shorthand for switch else fatalError().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161005/e0827abd/attachment.html>