On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
> I can see you saving a little bit of typing with this, but it's
> not worth it.


Um, it can actually save a lot of type and errors.

having two places to change is very error prone.

if (cond) { }
switch(cond)

If the condition is complex and one forgets it is the same condition then only changing one block will cause bugs.

It is not a hard feature to have AND it is worth it because it is a near zero complex compiler implementation.

So, depending on how you define "not worth it", which I take "I'm too lazy to implement it", you could be correct.

On Saturday, 3 August 2013 at 18:51:24 UTC, MattCoder wrote:
> On Saturday, 3 August 2013 at 18:04:03 UTC, Walter Bright wrote:
>> On 8/3/2013 10:45 AM, w0rp wrote:
>>> I can see you saving a little bit of typing with this, but it's
>>> not worth it.
>>
>> It would be a very unconventional syntactic form, and my experience with such things is it'll see very, very little use.
>
> I would like to use this topic and ask if it would be possible to extend a feature of D language like in this case related by the author.
>
> Imagine that a user want to put a trigger when "switch statement" match some option, wouldn't be nice if D could do something like this:
>
> switch(x){
>    onBeforeMatch = callFoo();
>
>    case n1:
>    ...
>    case n2:
>    ...
> }
>
> Where onBeforeMatch could be onAfterMatch.
>
> Matheus.

You can accomplish the exact same and more with my suggestion.

switch (x)
{
   common: callFooBefore();
   case n1: break;
   case n2: break;
   default: break;
   common: callFooAfter();
} else { }

This should be the standard template for switch statements... why we must not progress out of the 80's is beyond me...

What I really don't get it is why people think that just because they won't use such a feature then it must be useless to everyone else.

On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
> On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
>> I can see you saving a little bit of typing with this, but it's
>> not worth it.
>
>
> Um, it can actually save a lot of type and errors.
>
> having two places to change is very error prone.
>
> if (cond) { }
> switch(cond)
>
> If the condition is complex and one forgets it is the same condition then only changing one block will cause bugs.
>
> It is not a hard feature to have AND it is worth it because it is a near zero complex compiler implementation.
>
> So, depending on how you define "not worth it", which I take "I'm too lazy to implement it", you could be correct.

If the implementation is so obviously trivial why don't you implement a proof of concept? The compiler is open source after all.

People routinely underestimate the ripple effect that adding 'trivial' extensions to a language can have on a language.

On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
> If the implementation is so obviously trivial why don't you implement a proof of concept? The compiler is open source after all.

This seems like something that would be fairly simple to implement using a mixin template, so you may not have to go as far as hacking the compiler.

On 8/3/2013 12:00 PM, JS wrote:
> What I really don't get it is why people think that just because they won't use
> such a feature then it must be useless to everyone else.

You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal.

Consider, for example, the scope guard statement in D. It is extremely useful - but it is an unusual form (doesn't exist in other languages) and programmers just don't think in those terms. Andrei & I constantly have to work at 'selling' the benefits of it. It still hasn't really caught on.

On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
> On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
>> On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
>>> I can see you saving a little bit of typing with this, but it's
>>> not worth it.
>>
>>
>> Um, it can actually save a lot of type and errors.
>>
>> having two places to change is very error prone.
>>
>> if (cond) { }
>> switch(cond)
>>
>> If the condition is complex and one forgets it is the same condition then only changing one block will cause bugs.
>>
>> It is not a hard feature to have AND it is worth it because it is a near zero complex compiler implementation.
>>
>> So, depending on how you define "not worth it", which I take "I'm too lazy to implement it", you could be correct.
>
> If the implementation is so obviously trivial why don't you implement a proof of concept? The compiler is open source after all.

because I have better things to do and there is an extreme likelihood it won't be accepted.

> People routinely underestimate the ripple effect that adding 'trivial' extensions to a language can have on a language.

Um, and people routinely don't think hard enough about the problem to realize the feature is an orthogonal semantic that has no bearing on anything but what it does.

Why do I know this?

Because the feature is short hand notation that can be directly implemented the long way. If the long way doesn't have problems, then the short way does not have any problems(except if your implementation is bad, but that's not the fault of the short way).

I can write a preprocessor to do the things I need to do. I have done it before. The problem is it is hard to make such features robust without some grammatical context such as an ast.

On Saturday, 3 August 2013 at 19:51:33 UTC, JS wrote:
> ...

I am afraid creating your own language may be your only possibility to get a language that shares your views on "proper" design. Because with each new topic it becomes more and more clear that D is unlikely to fit into that picture.

Being useful for someone is _not_ enough to add a feature. It must be useful for a very large amount of cases and/or provide some advantage that can't be achieved in 3x-5x amount of code without it. Anything less than this does not pull its own weight.

On Saturday, 3 August 2013 at 19:22:53 UTC, Walter Bright wrote:
> On 8/3/2013 12:00 PM, JS wrote:
>> What I really don't get it is why people think that just because they won't use
>> such a feature then it must be useless to everyone else.
>
> You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal.


This is illogical. The code wasn't written with such a semantic in mind so it would require me to rewrite the library to see how useful it truly is. The semantic should stand on it's own. Either it extends some basic functionality in a good way or it doesn't. i.e., Does it add value? If it does, then it should be implemented assuming the implementation costs and maintenance is not high. In this case the implementation costs and maintenance is near constant(since it is an orthogonal semantic not impacting any other aspect in the compiler but the switch statement itself).

In fact, if the D compiler had some ability to easily implement transformations then one could simply rewrite the switch statement into what it represents.

Such transformations depend only on the local context(what you are immediately transforming) and simply rewrite the code into other code.

e.g.,

compiler see's

switch (cond)
{
    <common>: <common_body1> <body_end_statement>;
    case <symbol> : <case body> [break or return or fallthrough]
    ...
    <default> : <default_body>  [break or return or fallthrough]
    <common>: <common_body2> <body_end_statement>;
} else <else_body>

AND rewrites it to

if (cond) { <common_body1> }
switch (cond)
{
    case <symbol> : <case body> [break or return or fallthrough]
    ...
    <default> : <default_body>  [break or return or fallthrough]
}
if (cond) { <common_body2> }
if (!cond) { <else_body> }


The second is already valid D. The first is a "short hand" which is less error prone and less verbose. Since the transformation is rather trivial and, in a sense, "linear", it is very low impact to the maintenance and implementation of the compiler.

What it offers? Nothing to those that don't use it... everything to those that do.

> Consider, for example, the scope guard statement in D. It is extremely useful - but it is an unusual form (doesn't exist in other languages) and programmers just don't think in those terms. Andrei & I constantly have to work at 'selling' the benefits of it. It still hasn't really caught on.

And what I'm asking for is similar to scope guards for switch statements. You see how difficult is for me to "sell" it.

But you can't design a language for the lowest common denominator. The best language available is the one that can do it all for everyone. With such a language everything else will follow. Having features that no one will use is not necessary bad... at some point chances are someone will want that feature and use it.

For example, suppose what I am suggesting has zero cost to implement and maintain...

Would you allow it in D?

If not, why not? What are the drawbacks to having it? Is it error prone? Completely useless(Obviously not, because at least 2 people would find it useful)? etc...

Regarding the feature proposed here, I think the extra complexity added doesn't pay enough back.


Walter Bright:

> You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal.

Has someone done that regarding the last feature added to D, I mean the support for this syntax:

enum mysize(T) = T.sizeof;
template Pair(T) = Tuple(T, T);

Bye,
bearophile

On 8/3/2013 1:06 PM, JS wrote:
> On Saturday, 3 August 2013 at 19:22:53 UTC, Walter Bright wrote:
>> On 8/3/2013 12:00 PM, JS wrote:
>>> What I really don't get it is why people think that just because they won't use
>>> such a feature then it must be useless to everyone else.
>>
>> You could provide supporting evidence by examining every use of switch in the
>> dmd, phobos, and druntime source code, and see what percentage of those would
>> benefit from your proposal.
>
>
> This is illogical. The code wasn't written with such a semantic in mind so it
> would require me to rewrite the library to see how useful it truly is.

There are two kinds of semantic language improvements:

1. one that is transformative to programming style, i.e. you'd write your program in a fundamentally different way, like OOP.

2. one that is automating an existing pattern, which is finding a recurring pattern in code and providing syntactic sugar for it. The foreach loop is in this category.

Your proposal looks to me like (2), in fact, you wrote:

> Since the transformation is rather trivial

which supports that categorization.

So, to make automating an existing pattern worthwhile, there ought to be a significant percentage of code exhibiting that existing pattern.

For example, bearopile listed:

    enum mysize(T) = T.sizeof;

which does automate a commonly recurring pattern.

> You see how difficult is for me to "sell" it.

Yes, and it should be difficult to sell a new language feature.


> For example, suppose what I am suggesting has zero cost to implement and
> maintain...
>
> Would you allow it in D?

There's no such thing - and certainly your proposal is not. Any syntactic change requires an ongoing cost in:

1. implementation
2. maintenance
3. testing
4. documentation
5. users have to learn it
6. books and tutorials about D have to discuss it

Repeat steps 1..6 for every tool that deals with D source code.

Therefore, there needs to be an advantage to it that outweigh all of that. It's a high bar. This is true for every language out there, and if you invent your own language, you'll quickly start applying that criteria as well.