On 2/17/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 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.

There are some interesting related Phobos pulls:

Add functional style regex pattern-matching: https://github.com/D-Programming-Language/phobos/pull/1392

Add functional pattern matching for object references: https://github.com/D-Programming-Language/phobos/pull/1266

Add a functional switch function: https://github.com/D-Programming-Language/phobos/pull/1259

On 2/17/14, 5:33 AM, Manu wrote:
> On 17 February 2014 16:18, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 2/16/14, 7:42 AM, Manu wrote:
>
>         So D offers great improvements to switch(), but there are a few
>         small
>         things I wonder about.
>
>
>     TL;DR of my answer to this: at some point we must get used to the
>     notion that minute syntax tweaks are always possible that make us
>     feel we're making progress when instead we're just moving the rubble
>     around.
>
>
> OT: Do you realise how harsh your posts often appear to people? I often
> find I need to restrain myself when replying to your blunt dismissals of
> peoples opinions/suggestions.

You're right. I shouldn't have answered because now the thread is fueling from the answers it's getting. Well actually I did my best in my post to sugarcoat my opinion of the post, which I found a whine on minor issues and a collection of entirely petty proposals. Sorry.

Advanced pattern matching and safe downcasting and such - that may be valuable to discuss. But the concerns expressed in this thread build a store on saving on typing 'case' and 'break'.

> So, you admit that this is a disaster site, but are reluctant to
> consider what good may come of it?

I didn't admit that. (And I'm sure this is not an attempt to put words in my mouth.) That wasn't even the charge. I'll actually quote this thread's overture: "So D offers great improvements to switch(), but there are a few small things I wonder about."

> I'm not suggesting to move the rubble around a bit, I'm suggesting a
> missed opportunity to build something new and useful from the rubble.

I believe even if we implement all of these suggestions (change range syntax, "break" no longer required, no need for "default") to perfection, they would have zero consequence on the success of D. I really do believe that.

> There are like, 5 control statements in the language; if, for, while,
> foreach, switch. To trivialise their importance is surprising.

It would be surprising. But nobody is.

> switch is basically the same in D as in C, which kinda finds a purpose
> here and there, but it's built on a rubbish foundation. I can imagine
> switch (or something like it) being _extremely_ useful to address whole
> new classes of problems (like match in rust and others) if it were just
> a little bit less shit.

A match statement would be interesting, but was not asked for. This thread wrings hands over punctuation and formatting.

[snip some of the said hand wringing]

>     I think the current switch statement design is a fine design all
>     things considered (compatibility, law of least surprise, usability,
>     readability).
>
>
> Well, I disagree. It offers some improvement over the catastrophic
> design that C gave us almost half a century ago, but it doesn't address
> the basic un-structured nature of the statement, and deliberately
> retains all the elements that made it rubbish back when (for compatibility).
>
> Compatibility and law of least surprise I'll grant you.
> Usability and readability, I don't think so. Certainly not compared to
> competition.
>
> I think what's clear though, is in order to not violate the first 2
> (which I agree there is merit in maintaining), any improvement to switch
> would probably need to come in the form of a new structure, like 'match'
> in rust, or something designed from the ground-up to not suck, 'select'
> maybe.
>
> I concede that switch can't be fixed. Perhaps it should be deprecated
> instead.

I don't think we should deprecate switch. And if the to-be-proposed match/select's main features are small syntactic fixes to switch, I don't think they're worth adding.

> So I guess on that note, I'll leave it there, but I still think it's
> worth consideration.

Improving on "switch" is hardly the kind of thing that keeps me awake at night. Finalizing the language is. Threads. Garbage. Null pointers. this(this). Allocators. Dynamic libraries. Better punctuation for "switch" is not even down the list - it's not on the list. And I don't think it should. If that is, anything could be put on the list by the loudest voice asking.

> The functionality that switch offers is tremendously useful, and it
> would be so much more useful if it were cleaned up; people would
> actually use it, and probably in a whole bunch of new applications.

I don't think so. Again, I think a nicer switch syntax would do zero for the success of D.

[snip]

> Finally, you didn't address the suggestion to allow assignment of the
> switch condition to a properly scoped variable: switch([x =] expression) ?
> Some expression results don't have an easily named concept. Performing
> the expression on a prior line and assigning to a temp often results in
> some pretty stupid variable names polluting the outer scope. And it's
> annoying.

That bugzilla is a minor improvement that has precedent in the "if" statement, so I'd accept "switch (auto var = expr)" if implemented.


Andrei

On 02/17/2014 04:59 AM, Manu wrote:
> On 17 February 2014 03:14, Timon Gehr <timon.gehr@gmx.ch
> ...
>
>     Of course, I'd just write the above as:
>
>     int difficulty = e.note.note.between(60,108) ? (e.note.note-60)/12 : -1;
>
>
> Yes yes, very clever.

I can't agree.

> Obviously it's an example and could come in any shape or form.

Obviously. Hence, no need to point this out.

> Personally, I also wouldn't do that anyway; basic readability has
> definitely been lost.
> ...

IMO quite the opposite is true. And everything around it will tend to become simpler to follow at a glance as well.

>
>         The default case is a total waste, since -1 should just be
>         assigned when
>         initialising the variable above.
>         ...
>
>
>     How is the compiler supposed to know? It might be a logic error for
>     e.note.note to be out of range.
>
>
> Then I should have used an invariant or something actually designed for
> catching values out of range.
> It's not the compilers fault I made a logic error. I could make a logic
> error literally anywhere in my code. Why force an annoying rule

It's not inherent to the rule.

> to maybe sometimes catch exactly one case

Well, it is also not the kind of error I make, but it still documents intention. It would be easy to sloppily omit default: assert(0) without this rule without actually affecting correct code, but I wouldn't warmly recommend this practice.

> (while making other competing cases where a logic error isn't present more annoying).
>

That's roughly the dynamic typing argument. Obviously 'switch' is quite lame (being lame seems to be an inherent quality of statement-based syntax), but the requirement to explicitly handle the default case instead of implicitly skipping it is not why.

>
> OT: Do you realise how harsh your posts often appear to people? I often
> find I need to restrain myself when replying to your blunt dismissals of
> peoples opinions/suggestions.
>
> So, you admit that this is a disaster site, but are reluctant to consider
> what good may come of it?
> I'm not suggesting to move the rubble around a bit, I'm suggesting a missed
> opportunity to build something new and useful from the rubble.
>
> There are like, 5 control statements in the language; if, for, while,
> foreach, switch. To trivialise their importance is surprising.
> switch is basically the same in D as in C, which kinda finds a purpose here
> and there, but it's built on a rubbish foundation. I can imagine switch (or
> something like it) being _extremely_ useful to address whole new classes of
> problems (like match in rust and others) if it were just a little bit less
> shit.
> And it is shit, it's barely better than C; it's verbose, nobody knows how
> to format 'case' statements, it always seems to violate formatting
> standards whenever it's used (disagrees with all code everywhere else),
> programmers always seem to disagree on how it should be.
> In my opinionated opinion, it always seems to look ugly, and unnecessarily
> verbose.
>
> The ugliness of the syntax makes it an unattractive choice for application
> to many problems where it may have otherwise been applicable, simplifying
> code, and making the code more readable and understandable at a glance.
> The switch statement was obviously initially designed to improve clarity;
> anything that can be done with a switch statement can easily be done with a
> series of if's (if you love squinting at comparative conditions and
> constant repetition of the terms being compared), and it probably did
> improve clarity, in 1970's...
> But I think we could do much better, and offer an interesting and useful
> construct that could be used to clarify code in far more locations than it
> ever sees use today.
>

And do you realise that every sentence in your post is matter your your persona taste. It is extremely subjective, and you provide no proof that majority of people who are interested in all this share your opinion, do you? Do not get me wrong, I am not defending Andrei here (he can defend himself better than me). It is just shocking sometimes what kind of non-sense is posted here.

Let me dodge back few quotes of your post back at you to think about what I said in the paragraph above:
1) "built on a rubbish foundation"
2) "less shit" (no comment here...!)
3) "nobody knows how to format 'case' statements" (well, if you do not know, there are people who do)
4) "The ugliness of the syntax" (again your own taste)

If you scan your own post(s), you will find many examples of what I am saying. This attitude of yours won't get you far.

"Andrei Alexandrescu"  wrote in message news:ldtbcb$mel$1@digitalmars.com...

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

I doubt one can really know if it's a game changer until it has been implemented and experimented with.  I'm not really in a position to design one for D, but I have had some positive experience with erlang's 'case' expressions.  The real question is if we can make it clean and powerful enough to outdo a library solution.

> But that's not quite what has been proposed in this thread.

Yeah, I was trying to derail this thread in a more useful direction. 

On 18 February 2014 02:48, Dejan Lekic <dejan.lekic@gmail.com> wrote:

>
>> [snip]
>>
>
> And do you realise that every sentence in your post is matter your your persona taste. It is extremely subjective, and you provide no proof that majority of people who are interested in all this share your opinion, do you? Do not get me wrong, I am not defending Andrei here (he can defend himself better than me). It is just shocking sometimes what kind of non-sense is posted here.
>

Yes, they're obviously opinions. I wouldn't use phrasing like that if I
wasn't trying to demonstrate my strong opinion on the matter.
I only raised some details that are annoying me, I didn't say I had any
science to show it was a majority opinion. I'm not sure why that's
necessary to make an opinion oriented post.
A large part of the reason for posting in the first place is to find if/how
many people also feel that way. That's the nature of opinions, I don't know
what other peoples are until I talk about it.


Let me dodge back few quotes of your post back at you to think about what I
> said in the paragraph above:
> 1) "built on a rubbish foundation"
> 2) "less shit" (no comment here...!)
> 3) "nobody knows how to format 'case' statements" (well, if you do not
> know, there are people who do)
> 4) "The ugliness of the syntax" (again your own taste)
>
> If you scan your own post(s), you will find many examples of what I am saying. This attitude of yours won't get you far.
>

Well, I firmly stand by all those convictions. They also look worse out of
context.
I don't think switch is particularly good, and firmly believe C's switch
statement was (is) a design catastrophe. I've believed that for 20 years.
You're welcome to disagree, and tell me why you do. I might even change my
opinion if someone can convince me it's awesome the way it is for some
reason.
I've spent 3 days basically writing switch statements. I haven't enjoyed
it, and I feel the experience is a big missed opportunity.

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.

On 2/17/2014 5:33 AM, Manu wrote:
>         We can compact it a bit 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;
>         }
>
>         But that's horrible too.

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.

> Finally, you didn't address the suggestion to allow assignment of the switch > condition to a properly scoped variable: switch([x =] expression) ?

That's probably a good idea.

On 2/17/2014 10:03 AM, Manu wrote:
> Well, I firmly stand by all those convictions. They also look worse out of context.
> I don't think switch is particularly good, and firmly believe C's switch
> statement was (is) a design catastrophe. I've believed that for 20 years. You're
> welcome to disagree, and tell me why you do. I might even change my opinion if
> someone can convince me it's awesome the way it is for some reason.
> I've spent 3 days basically writing switch statements. I haven't enjoyed it, and
> I feel the experience is a big missed opportunity.

Having strong convictions is good, but strong reactions to them come with the territory :-)

On 2/17/2014 5:48 AM, Ary Borenszweig wrote:
> On 2/16/14, 5:03 PM, Walter Bright wrote:
>> It originally was not required, but there was a campaign by a lot of D
>> users to make it required to deal with the common bug of adding a value
>> in one switch statement but forgetting to add it to another
>> corresponding one.
>
> Could you show an example of such scenario? I don't get it.

Having a set of bit flags, and adding another bit flag later, and failing to account for that in existing switch statements.