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

> On 5 Oct 2016, at 15:29, Haravikk via swift-evolution > wrote: > > > 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 s

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

> On Oct 5, 2016, at 8:29 AM, Haravikk via swift-evolution > wrote: > > >> On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I think I agree with you. The postfix `!` operator is always shorthand for >> `fatalError()` (and some mor

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

> On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution > 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

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

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 ha

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

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 inc

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

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 “

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

The best answer is always "that would be an ecumenical matter...". It works here too ;). Sent from my iPhone > On 4 Oct 2016, at 03:44, Matthew Johnson via swift-evolution > wrote: > > >> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Oct 3, 2016, at 9:3

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

> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution > wrote: > > >> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution >> wrote: >> >> -1 in general. I want smarter exhaustiveness analysis, but I don’t want to >> be able to ignore cases that “can’t happen” (so say we,

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

> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution > wrote: > > -1 in general. I want smarter exhaustiveness analysis, but I don’t want to > be able to ignore cases that “can’t happen” (so say we, writer of bugs) when > they’re clearly in the domain of possible values that can

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

If you're as concerned about code size as stdlib is then I'd be interested to know what you're writing! These are paths to terminate your application which is necessarily going to be orders of magnitude larger than stdlib is and so can "eat the cost" of a few more global db's, some loads, and a

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

-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, i

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

Yes, but uses `Builtin.unreachable()` because it: > "Saves a bit of code size in the standard library by eliminating some > static strings and function calls." Clang has both `__builtin_unreachable()` and `llvm_unreachable()`:

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

fatalError has defaults for its arguments so it can be used as a nullary unreachable function already. ~Robert Widmann > On Oct 3, 2016, at 2:50 PM, Ben Rimmington via swift-evolution > wrote: > > Instead of using `fatalError(_:file:line:)` in `default` cases, would a > public `unreachable()

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

Instead of using `fatalError(_:file:line:)` in `default` cases, would a public `unreachable()` function be more efficient? e.g. -- Ben > On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution > wrote: > > -1 from me too. > > Avoiding having to

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

-1 from me too. Avoiding having to write "default: break" isn't a good justification to introduce new syntax. It would make the understanding of case switches harder without providing any real benefit for the syntax bloat. João Pinheiro > On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolutio

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

I agree with previous commenters. I very much support improved exhaustiveness analysis reducing the circumstances where a default clause is necessary. But I think requiring it unless the compiler can *prove* you have covered every possibility communicates important information that facilitates

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

-1 from me as well. This suggestion falls into the same category as those about making `else` optional after `guard`, which is repeatedly rejected. Since code is read more often than written, explicit handling of the default case never hurts and can increase clarity. Not having to write `default: b

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

-1 in general. I want smarter exhaustiveness analysis, but I don’t want to be able to ignore cases that “can’t happen” (so say we, writer of bugs) when they’re clearly in the domain of possible values that can be fed to a switch-case. Exhaustiveness guarantees wellformedness of a program that

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

> On 03 Oct 2016, at 13:16, Ross O'Brien wrote: > > There has been a little discussion on this before, and I think there's a need > for something along these lines - I've written code where I've used 'guard' > to ensure that an Int was within a certain range, and then performed a switch > on

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

> On 3 Oct 2016, at 11:14, Adrian Zubarev via swift-evolution > wrote: > > I know that there is this note in Commonly Rejected Changes: > > 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

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

I’m not sure about the design itself, but the idea is great. I couldn’t even foresee that there might be a need for switch!. This is definitely better than my suggestion of a new attribute. I most cases I’d need switch? to replace the ugly-looking if case … { … } else if case … { … }. Was there

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

In my code, I ‘use’ the forced coverage of the case’s to be reminded of area’s where I have to update my code when the enum’s change. I.e. choosing for an enum solution is partly motivated by the factor that case-coverage has to be complete. I’d hate to miss that. Rien. > On 03 Oct 2016, at 12:

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

There has been a little discussion on this before, and I think there's a need for something along these lines - I've written code where I've used 'guard' to ensure that an Int was within a certain range, and then performed a switch on the Int, requiring an ugly-looking 'default: fatalError()' at th

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

This is clearly not a huge issue to solve, but a pitch is a pitch. From Swift book we know this: Switch Statements Must Be Exhaustive In Swift, every possible value of the control expression’s type must match the value of at least one pattern of a case. When this simply isn’t feasible (for ins

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

On non-enum values, yes I could support this. However I do not see this as a big enough issue. On enum values? no way…. Btw this would get rid of: let bytesSend = send(…) // returns an Int switch bytesSend { case Int.min ... -1: {…} case 0: {…}

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

I know that there is this note in Commonly Rejected Changes: 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 mat