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 <[email protected]> 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 
> <[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to