On 2/17/2014 6:54 PM, Manu wrote:
> Me too, but you don't feel this is basically a hack?

I see nothing hackish about it. After all, there's a reason D does not enforce whitespace.


> About half of that text is repeated cruft, and there's no precedent for
> formatting well-structured code like that anywhere else in the language.
> How long would you say you spend on average fiddling with the tabulation?
> I am known to spend minutes pressing the space bar, trying to make it line up
> and look nice. And then invariably, some other case comes along, with a slightly
> longer identifier name, and you have to work your way up shifting everything
> around against with a bunch more spaces.. pollutes source control history, etc.
> And then that case with the REALLY long identifier name comes along, and you end
> out with so many spaces surrounding all the other cases, that it becomes
> difficult to associate which line matches which case, so then you think to
> yourself, "this one long case is ruining my code, maybe I should break the
> pattern and fall this long one onto it's own line below...", and then you're
> just wasting time, pushing the spacebar key, trying to work around something
> that shouldn't have been an issue in the first place.
> Often enough the break statements end up far off the right hand side of the
> screen due to that one long statement in the sequence; do you line them all up
> religiously far to the right? Or do you make an exception for that one long
> line, allowing it to span beyond the 'break' line, and keep the rest lined up
> nearer to the code they terminate?
> Tell me this doesn't happen to you? Surely I'm not the only one that faces this
> sort of conundrum frequently when I try and use switch? :)

Shirley you're joking. If that's the hardest problem you face programming in D, I am well satisfied that D is a great design!

On 18 February 2014 05:51, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/17/2014 5:49 AM, Manu wrote:
>
>> Refer to my other reply wrt the 'rubble' concept.
>>
>
> Sure :-)
>
>
>
>  I think a quality implementation would be fairly game changing. A properly
>> scoped and fully featured switch/select/match statement would result in
>> some
>> radical simplifications of code all over the place.
>>
>
> I have a real hard time seeing the proposed changes as radical or game changing.
>
>
>
>  If switch (or something like it) were massaged to be as nice to use as
>> foreach
>> is, I think you'll find it will be used all over the place.
>>
>
> foreach() is quite a large improvement, because by abstracting away the mechanics of iteration, code need no longer be aware of just what abstract type is being looped over. Furthermore, it eliminates several common sources of coding bugs.
>
> I'm not seeing this with changes in switch.
>

I think abstracting away volumes of comparative matching logic is similarly
interesting to eliminating tedious iteration logic. I find out-by-ones and
bogus comparisons that I didn't spot is a very common class of bug (often
just because matching code is long and repetitive).
Cut and paste, oops; you didn't spot that <= is actually >= from where you
cut... or you didn't see it because the line is so long with repetition of
the terms being compared that it's run off the right edge.
*disclaimer: peoples experiences may differ, this is my experience.

I agree, it's probably not as game-changing as foreach, but I think if you had it for a few years and became accustomed to writing much of that comparative logic in a simple and really obvious/less-repetitive way, you'd look back and wonder how you did without it. I suspect it's possible that the repetitive matching logic often found in if() statements represent a lot more code by volume than the iteration logic eliminated by foreach ever did in for loops.

I can't say how big a deal it is until I make a habit of applying it everywhere, but I can imagine the potential for massive improvement in readability, and elimination of many long if() expressions.

Comparing the savings:

for(int i=0; i<things.length; ++i)
->
foreach(i, thing; things)


if(thing.member >= min && thing.member < max)
->
match(thing.member)
 case(min..max)

If an 'else if' appears, the savings compound considerably.


I'm a practicality motivated programmer, I don't dream about futuristic features as much as I respond to the things that annoy me consistently on a daily basis. I don't like friction between me and getting my work done, and it's the little things that come up most often that tend to really bug me. I'd like to think the languages foundational keywords should offer a good experience. You'll be typing them over and over again from now until the day you die. Looking at other languages, I think there's clearly a missed opportunity to do something a lot more modern and useful with the switch concept.

Rust does it nice. It's got a nice functional flavour to it.

On Tuesday, 18 February 2014 at 04:02:35 UTC, Walter Bright wrote:
> Shirley you're joking. If that's the hardest problem you face programming in D, I am well satisfied that D is a great design!

http://www.youtube.com/watch?feature=player_detailpage&v=KM2K7sV-K74#t=5

On 18 February 2014 14:02, Walter Bright <newshound2@digitalmars.com> wrote:
>
>
> Shirley you're joking. If that's the hardest problem you face programming in D, I am well satisfied that D is a great design!
>

I didn't say that. But I do think it's more significant than it appears. If people deliberately avoid a fundamental structure because it's awkward and in many cases it doesn't offer a clarification of their code in practise, when it easily could/should have, I think that's a significant loss.

Note; that's a commentary on one criticism relating to one particular pasted block of code wrt switch as it exists right now. It's not a summary of all my thoughts presented in this thread, just a single facet of my post.

On 2/16/2014 10:59 PM, Manu wrote:
> On 17 February 2014 03:14, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>
>> int difficulty=-1;
>>
>> switch(e.note.note){
>>      case 60: .. case 71:  difficulty = 0; break;
>>      case 72: .. case 83:  difficulty = 1; break;
>>      case 84: .. case 95:  difficulty = 2; break;
>>      case 96: .. case 107: difficulty = 3; break;
>>      default: break;
>> }
>>
>
> I hate this. It violates the formatting conventions used EVERYWHERE else.
> In terms of formatting, it doesn't even look like the same language.

I find it extremely easy to read, and much nicer than the other options. Being able to omit break and use switch as an expression would be a little nicer still, but I still fail to see why the above, no matter how it's formatted, is so terribly intolerable.

On 2/17/2014 9:54 PM, Manu wrote:
> On 18 February 2014 06:00, Walter Bright <newshound2@digitalmars.com> wrote:
>>
>>
>> I tend to format such like this:
>>
>>
>>           int difficulty;
>>           switch(e.note.note)
>>           {
>>             case 60: .. case 71:  difficulty = 0;  break;
>>             case 72: .. case 83:  difficulty = 1;  break;
>>             case 84: .. case 95:  difficulty = 2;  break;
>>             case 96: .. case 107: difficulty = 3;  break;
>>             default:              difficulty = -1; break;
>>           }
>>
>> By lining things up, it takes on a tabular appearance. People are good at
>> inferring patterns, and such tabular arrangements make it easy to spot
>> squeaky wheels.
>
>
> Me too, but you don't feel this is basically a hack?
> About half of that text is repeated cruft, and there's no precedent for
> formatting well-structured code like that anywhere else in the language.
> How long would you say you spend on average fiddling with the tabulation?

I use the formatting posted above, and it takes me very, very little time.

> I am known to spend minutes pressing the space bar, trying to make it line
> up and look nice. And then invariably, some other case comes along, with a
> slightly longer identifier name, and you have to work your way up shifting
> everything around against with a bunch more spaces.. pollutes source
> control history, etc.

Sounds like you need elastic tabstops:

http://nickgravgaard.com/elastictabstops/

I don't use them personally since PN2 doesn't support them yet, but they're a brilliant idea and they do solve that re-aligning issue. Word processors figured out how tabstops are supposed to work ages ago. Elastic tabstops really just amount to bringing code editors' ancient tab-handling up-to-date with the 90's.

> And then that case with the REALLY long identifier name comes along, and
> you end out with so many spaces surrounding all the other cases, that it
> becomes difficult to associate which line matches which case, so then you
> think to yourself, "this one long case is ruining my code, maybe I should
> break the pattern and fall this long one onto it's own line below...", and
> then you're just wasting time, pushing the spacebar key, trying to work
> around something that shouldn't have been an issue in the first place.
> Often enough the break statements end up far off the right hand side of the
> screen due to that one long statement in the sequence; do you line them all
> up religiously far to the right? Or do you make an exception for that one
> long line, allowing it to span beyond the 'break' line, and keep the rest
> lined up nearer to the code they terminate?
> Tell me this doesn't happen to you? Surely I'm not the only one that faces
> this sort of conundrum frequently when I try and use switch? :)

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.

On 2/17/2014 10:54 AM, Andrei Alexandrescu wrote:
> On 2/17/14, 7:42 AM, Daniel Murphy wrote:
>>
>> Exactly, foreach is a new, better language construct, but we didn't
>> butcher for.  I would love to see a nice solid proposal for 'match'.
>
> A "match" statement that figures type patterns and introduce names and
> all that - that might be more interesting (though being far from a game
> changer). But that's not quite what has been proposed in this thread.
>

Although I've said it before, I'd love to see Nemerle's match in D:

https://github.com/rsdn/nemerle/wiki/Quick-guide#wiki-Pattern_Matching

Especially together with its great algebraic types (Phobos's Algebraic still needs some beefing up, unfortunately).

On Mon, 17 Feb 2014 22:53:15 -0500, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/17/2014 6:17 PM, Steven Schveighoffer wrote:
>> How is this advantageous? It just seems annoying...
>
> Because it makes the programmer's intent clear - are all the cases accounted for, or are there defaults?
>
> 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.

-Steve

On 2/18/14, 11:56 AM, Steven Schveighoffer wrote:
> On Mon, 17 Feb 2014 22:53:15 -0500, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 2/17/2014 6:17 PM, Steven Schveighoffer wrote:
>>> How is this advantageous? It just seems annoying...
>>
>> Because it makes the programmer's intent clear - are all the cases
>> accounted for, or are there defaults?
>>
>> 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.
>
> -Steve

Exactly. Programmers will just put "default: break" because of this annoyance without thinking too much if it should be this or assert(0).

I think that "final switch" should have the function of checking that you covered all cases, be it with a default case or not.

"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.