On 06/21/2010 06:56 PM, Jonathan M Davis wrote:
> Andrei Alexandrescu wrote:
>
> [snip]
>>
>>
>> Andrei
>
> Well, "goto case" and "goto case XXX" both already exist. Both get the job
> done. So, regardless of which would be better for fallthrough, we can choose
> to use whichever we want in our code. As it stands, it becomes a matter of
> preference. I'd love something like "continue switch" or "fallthrough" to
> indicate explicit fallthrough, but it isn't at all necessary, so it's not
> worth trying to get Walter to add anything like that.
>
> At this point, if Walter makes it so that case blocks must end with a flow
> control statement of some kind, we're free to use either "goto case" or
> "goto case XXX" for fallthrough, so unless "goto case" is so bad that we
> should try to get Walter to get rid of it, I don't think that it's really an
> issue. We can use whichever one we want and not worry about it. The language
> is complete enough to require case statements to end with a control
> statement without losing any flexibility, so I think that we can agree to
> disagree on which statement is better and/or clearer and try and get Walter
> to add the compiler error for naked fallthrough.

I think that's fair enough. It's really Walter's decision now, and Don's too (because with Walter busy with the 64-bit implementation, it's likely Don is the one to volunteer to implement the thing).

Andrei

Andrei Alexandrescu, el 21 de junio a las 15:31 me escribiste:
> On 06/21/2010 03:08 PM, Don wrote:
> >Andrei Alexandrescu wrote:
> >>On 06/19/2010 06:58 AM, Don wrote:
> >>>Andrei Alexandrescu wrote:
> >>>>Don wrote:
> >>>>[snip]
> >>>>>Or is too late to break backwards compatibility with B ?
> >>>>
> >>>>We can and should do it. It won't impact TDPL adversely.
> >>>
> >>>Excellent! I'll make a patch for it when I have time.
> >>
> >>Walter just gave the green light, so Don - it's up to you.
> >
> >I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code written by at least 4 different people. I think everyone gets stung by that B.
> 
> This is pretty amazing. Can't wait to see the checkin!
> 
> It might be interesting to see how many bugs are caught by restricting the switch statement.

There is already a patch for that: http://d.puremagic.com/issues/show_bug.cgi?id=3536

Maybe is not perfect (it adds a new flavour of case to allow implicit fall-through), but it's something =). And just to experiment with, it should be good enough, since it makes the default case syntax forbids implicit fall-through, so it's not necessary to change any code to try it (if it still applies to trunk, which probably is not the case anymore).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ya ni el cielo me quiere, ya ni la muerte me visita
Ya ni el sol me calienta, ya ni el viento me acaricia

Andrei Alexandrescu, el 21 de junio a las 15:25 me escribiste:
> On 06/21/2010 01:27 PM, Sean Kelly wrote:
> >Jonathan M Davis Wrote:
> >>
> >>In any case, that means that it could be made required to have a control statement at the end of a case block without having to specify a specific destination for fallthrough - though I'd prefer "continue switch" over "goto case" since it's more explicit and less error prone (since there's no doubt that you didn't intend to put a destination for the goto if you use "continue switch" instead of a "goto case" without a destination).
> >
> >It's a small thing, but I think "continue switch" could be misleading.  Consider this:
> >
> >switch (getState()) {
> >case X:
> >     setState(Z);
> >     continue switch;
> >case Y:
> >     break;
> >case Z:
> >     writeln( "done!" );
> >}
> >
> >Having never encountered D before, what would be your interpretation of this code?
> 
> Well looks pretty good to me to be honest.

goto next case; is a little more verbose but very clear to me :)

Maybe just next case; is a shorter alternative...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
CONDUCTOR BORRACHO CASI PROVOCA UNA TRAGEDIA: BATMAN UNICO TESTIGO
	-- Crónica TV

On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lucarella <luca@llucax.com.ar> wrote:
> goto next case; is a little more verbose but very clear to me :)
>
> Maybe just next case; is a shorter alternative...

That would be great if "next" were a D keyword.  But I don't think you're going to get Walter to add a keyword just for this.

--bb

What's the point of a switch without implicit fallthrough? If you take that away, it offers nothing that if/elseif doesn't. (Aside from not retyping the switch(stuff here), which you can bring into a function anyway, so whoop-de-doo. And I guess some performance boosts in rearranging the cases, but can't the optimizer do that in if/else anyway?)

int Case(in int value) { return myvar == value; }

if(Case(10)) {

} else if (Case(20)) {

} else  { /* default */ }

You can even use goto and labels to simulate goto case.


I'm quite serious here: fallthrough is the defining feature of the switch. Taking it away leaves you with nothing that if/elseif can't already do. Might as well just axe the whole thing.

Oh yeah, the final switch would still be useful, since it offers a check that if/elseif doesn't, but meh, move it to std.typecons, since it is mostly for enums anyway.


(I'm not actually for removing the switch. I'm firmly in the status quo camp.)

On 06/21/2010 07:40 PM, Adam Ruppe wrote:
> What's the point of a switch without implicit fallthrough? If you take
> that away, it offers nothing that if/elseif doesn't. (Aside from not
> retyping the switch(stuff here), which you can bring into a function
> anyway, so whoop-de-doo. And I guess some performance boosts in
> rearranging the cases, but can't the optimizer do that in if/else
> anyway?)
>
> int Case(in int value) { return myvar == value; }
>
> if(Case(10)) {
>
> } else if (Case(20)) {
>
> } else  { /* default */ }
>
> You can even use goto and labels to simulate goto case.
>
>
> I'm quite serious here: fallthrough is the defining feature of the
> switch.

Then why are people using switch and next to nobody uses fall through (provably including Walter, who thinks is using fall through "all the time")? Simple: because it's a structure expressing handling of a value against a set of values, whereas cascaded if/else is more general and therefore less structured.

The same argument could be made in favor of axing for since we already have while.


Andrei

Jonathan M Davis, el 21 de junio a las 17:03 me escribiste:
> bearophile wrote:
> 
> > Andrei Alexandrescu:
> >> The problem is, if Walter sees us bickering too much, he'll use that as pretext to veto out any improvement.
> > 
> > You are wrong, Walter is an adult able to understand discussions, not a capricious dictator :-) Syntax and other things require discussions, sometimes even longish ones.
> > 
> > Bye,
> > bearophile
> 
> Yes, he's an adult, but if he's not particularly interested in the change to begin with, and the folks who want the change can't agree on what the change should be, he could easily choose to leave things as they are - especially because things work just fine as they are. We'd like to be able to make a particular error harder to make, but it's not exactly a groundbreaking change. Walter could decide to work on more important things rather than worrying about this one. There's nothing childish about that.

There is *already* a patch by Chad Joan: http://d.puremagic.com/issues/show_bug.cgi?id=3536

It's not exactly the same proposed here, but if Walter gives green light maybe he'll be happy to update it. Just give him some feedback in that bug report when Walter is comfortable with the change.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si por el chancho fuera, se autocomería con chimichurri Worshestershire!

Bill Baxter, el 21 de junio a las 17:13 me escribiste:
> On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lucarella <luca@llucax.com.ar> wrote:
> > goto next case; is a little more verbose but very clear to me :)
> >
> > Maybe just next case; is a shorter alternative...
> 
> That would be great if "next" were a D keyword.  But I don't think you're going to get Walter to add a keyword just for this.

Damn! Where did I get next from? I don't know...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
"All mail clients suck. This one just sucks less." -me, circa 1995

Adam Ruppe, el 21 de junio a las 20:40 me escribiste:
> What's the point of a switch without implicit fallthrough? If you take that away, it offers nothing that if/elseif doesn't. (Aside from not retyping the switch(stuff here), which you can bring into a function anyway, so whoop-de-doo. And I guess some performance boosts in rearranging the cases, but can't the optimizer do that in if/else anyway?)
> 
> int Case(in int value) { return myvar == value; }
> 
> if(Case(10)) {
> 
> } else if (Case(20)) {
> 
> } else  { /* default */ }
> 
> You can even use goto and labels to simulate goto case.
> 
> 
> I'm quite serious here: fallthrough is the defining feature of the switch. Taking it away leaves you with nothing that if/elseif can't already do. Might as well just axe the whole thing.
> 
> Oh yeah, the final switch would still be useful, since it offers a check that if/elseif doesn't, but meh, move it to std.typecons, since it is mostly for enums anyway.
> 
> 
> (I'm not actually for removing the switch. I'm firmly in the status quo camp.)

Well, while, do..while are also redundant, you can do it with for. And you can do for with goto!

The point is providing a nice syntax for common usage patterns, and switch without fall-through is way more common than switch with fall-through, even when fall-through might been the primary "feature" provided by switch in its early ages.

And you can still use fall-through with the proposed semantics of switch, it's just making it explicit instead of implicit.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
TIGRE SE COMIO A EMPLEADO DE CIRCO: DETUVIERON A DUEÑO Y DOMADOR
	-- Crónica TV

Hello Jonathan,

> "goto case" does seem a bit silly, but I think that it's clearer and
> less error prone for anyone who understands "goto case."

Say I have some code with a fall through. If I use the goto case X; version, it allows the cases to be freely reordered. OTOH if I use the other option, it doesn't. I think that the more likely error is for someone to rearrange my code and not notice that a case falls thought (with goto case; this causes a bug) rather than rearrange it and expect it to fall through where it doesn't (with goto case X; this causes a bug). For one thing, if you want it to fall thought, you are already thinking about that issue.

-- 
... <IXOYE><