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

[Tim Vermeulen]

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> 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`.
> On Tue, Oct 4, 2016 at 3:35 AM Tim Vermeulen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I agree about exhaustiveness checks being very useful. There was a suggestion for `switch?` implicitly adding `default: break`, `switch!` implicitly adding `default: fatalError()`, and `switch` remaining as it is now. I think that’s a great compromise, would you be in favor of that?
> 
> > -1. The “default: break” is not only not difficult to write, it clearly communicates the programmer’s intent to only handle a subset of the cases. Without it, it is impossible to know whether that was intended, or by accident. Furthermore, the exhaustiveness by default can catch many mistakes, including after an additional case is added to an enum.
> >
> > Charles
> >
> > > On Oct 3, 2016, at 5:14 AM, Adrian Zubarev via swift-evolution<swift-evolution at swift.org <http://swift.org/>>wrote:
> > >
> > > I know that there is this note in Commonly Rejected Changes<https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>>:
> > >
> > > Remove support for default: in switch and just use case _:: default is widely used, case _ is too magical, and default is widely precedented in many C family languages.
> > > I really like to use the switch instead of if case for pattern matching, just because it’s neat block design. I do not want to remove default from switches because it’s a must have and powerful feature.
> > >
> > > I’d like to know why switches must be exhaustive.
> > >
> > > switch someValue {
> > >
> > > case …:
> > > // Do something
> > >
> > > case …:
> > > // Do something else
> > >
> > > default:
> > > () // useless nop; do nothing when no pattern matched
> > > }
> > >
> > > // VS:
> > >
> > > if case … {
> > >
> > > } else if case … {
> > >
> > > } else if case … {
> > >
> > > } // No need for `else`
> > > Can’t we make default optional, or at least on non-enum values?
> > >
> > >
> > >
> > >
> > > --
> > > Adrian Zubarev
> > > Sent with Airmail
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org <http://swift.org/><mailto:swift-evolution <mailto:swift-evolution> at swift.org <http://swift.org/>>
> > > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution><https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>>
> >
> >
> >
> _______________________________________________
> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161004/dc13e029/attachment-0001.html>