February 18, 2014
On Tue, 18 Feb 2014 11:11:36 -0500, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xbhfr5kreav7ka@stevens-macbook-pro.local...
>
>> > Of course, no compiler can make you write correct code. But if you're going to write a default anyway, odds are you'll choose the right one.
>>
>> I think your anecdotal experience with exception specification in Java is at odds with this expectation.
>>
>> We all know programmers who are faced with seemingly annoyance hoops to jump through jump through them with the least possible effort.
>
> It's not really the same, because silencing checked exceptions results in a solution that is worse than not having checked exceptions at all.  Here if the programmer takes the 'easy route' and sticks in a "default: break;" they're just getting the old behavior back.

My point though, is that the change to require default gains you nothing except annoyed programmers. Why put it in?

I see your point that the difference between ignored exceptions and pass-through exceptions is a lot different than breaking by default on a switch statement. But I wasn't trying to make that comparison, just using it as an example of what programmers do.

The comparison I AM making is that we are implementation a requirement that will not achieve the behavior goal it sets out to achieve.

-Steve
February 18, 2014
On Tue, 18 Feb 2014 11:38:41 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> The comparison I AM making is that we are implementation a requirement that will not achieve the behavior goal it sets out to achieve.

*implementing*, not implementation :)

-Steve
February 18, 2014
"Steven Schveighoffer"  wrote in message news:op.xbhkirppeav7ka@stevens-macbook-pro.local...

> My point though, is that the change to require default gains you nothing except annoyed programmers. Why put it in?

It only gains you nothing if you respond to the error by mindlessly putting a default: break; in.

The compiler is trying to help you by getting you to take an extra second and explicitly state what you what.  If you are automatically silencing the error without thinking about the semantics you want, you absolutely should be irritated, but the compiler is not the one doing something stupid here.

The awful part of checked exceptions comes from two place IMO - the ide gives you a very very easy way to do thing wrong thing (two clicks IIRC), and doing the right thing is often very very difficult (change exception lists on every calling functions).

Here the right and wrong choice are about equal difficulty - trivial.  I think complaints about typing those extra couple dozen keystrokes are on the same level as "why do I have to put these ';'s everywhere" and "'immutable' has too many letters". 

February 18, 2014
On Tuesday, 18 February 2014 at 06:00:25 UTC, Nick Sabalausky wrote:
> Erm, between all of that, plus your strong objection to "default: break;", I really do get the impression you're just simply being very OCD about this stuff. I don't mean that as an insult, I just think it's all a bit "Adrian Monk of source code", if you're familiar with the reference.

I have code formatting OCD. Switch case is an abomination. It looks nice with spaces and all, but anything that can't be identified by an auto formatter should die in a fire.

Also, I use arbitrary empty structs in my multi threading code as tokens. The type pattern matching of the mailbox looks nice. Unlike the switch case statements.

Tl;dr: Manual indentation, ew. Identically indented } on multiple lines, ew.
February 18, 2014
On Tue, 18 Feb 2014 12:26:36 -0500, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xbhkirppeav7ka@stevens-macbook-pro.local...
>
>> My point though, is that the change to require default gains you nothing except annoyed programmers. Why put it in?
>
> It only gains you nothing if you respond to the error by mindlessly putting a default: break; in.
>

It may not be mindless. Most people who want to handle the default case do it. It's usually not so much "I didn't think of handling other values," it's more "I never expect other values to come in, go away annoying compiler error."

> Here the right and wrong choice are about equal difficulty - trivial.  I think complaints about typing those extra couple dozen keystrokes are on the same level as "why do I have to put these ';'s everywhere" and "'immutable' has too many letters".

I think it's the same as saying you have to always have an else clause after an if statement, even if it's "else {}"

-Steve
February 18, 2014
On 2/18/14, 2:26 PM, Daniel Murphy wrote:
> "Steven Schveighoffer"  wrote in message
> news:op.xbhkirppeav7ka@stevens-macbook-pro.local...
>
>> My point though, is that the change to require default gains you
>> nothing except annoyed programmers. Why put it in?
>
> It only gains you nothing if you respond to the error by mindlessly
> putting a default: break; in.
>
> The compiler is trying to help you by getting you to take an extra
> second and explicitly state what you what.  If you are automatically
> silencing the error without thinking about the semantics you want, you
> absolutely should be irritated, but the compiler is not the one doing
> something stupid here.
>
> The awful part of checked exceptions comes from two place IMO - the ide
> gives you a very very easy way to do thing wrong thing (two clicks
> IIRC), and doing the right thing is often very very difficult (change
> exception lists on every calling functions).
>
> Here the right and wrong choice are about equal difficulty - trivial.  I
> think complaints about typing those extra couple dozen keystrokes are on
> the same level as "why do I have to put these ';'s everywhere" and
> "'immutable' has too many letters".

The compiler should force you to write an "else" for every if then:

if (a == 2) {
  // do something
}

Error: missing else

if (a == 2) {
  // do something
} else {
  nothing;
}

Or maybe:

if (a == 2) {
  // do something
} else {
  assert(0);
}

I think the main complaint is that if you refactor a chain of if/else-if into a switch statement, then you have to add a "default: break;" for sure, which is just redundant.
February 18, 2014
On 2/18/14, 2:52 PM, Steven Schveighoffer wrote:

> I think it's the same as saying you have to always have an else clause
> after an if statement, even if it's "else {}"

Lol, I swear I didn't read your answer before posting mine.

February 18, 2014
On Sunday, 16 February 2014 at 15:43:31 UTC, Manu wrote:
> 1.
> case fall-through is not supported;

goto case; automagically goes to the next case.

> 2.
> 'case 1, 3, 7, 8:' is awesome! ...but ranged cases have a totally different
> syntax: 'case 1: .. case 3:'
>
> Why settle on that syntax? The inconsistency looks kinda silly when they
> appear together in code.

When implementing this on SDC. The .. syntax seems appropriate to
me, the current one is clearly insane.

> 3.
> Why is 'default' necessary? If I'm not switching on an enumerated type,
> then many values are meaningless. requiring an empty 'default: break;' line
> at the end is annoying and noisy.

Sounds like an improvement over conventional switches to me.
February 18, 2014
On 2/18/2014 7:45 AM, Ary Borenszweig wrote:
> I think that "final switch" should have the function of checking that you
> covered all cases,

That's just what it does.

> be it with a default case or not.

final is meaningless with a default.

February 18, 2014
On 2/18/2014 8:38 AM, Steven Schveighoffer wrote:
> My point though, is that the change to require default gains you nothing except
> annoyed programmers. Why put it in?

This was fiercely debated at length and settled here years ago. It isn't going to change.


> The comparison I AM making is that we are implementation a requirement that will
> not achieve the behavior goal it sets out to achieve.

It's been this way for years now, if there was emergent bad behavior, it would be obvious by now. But I haven't heard any reports of such.