On 8/3/2013 12:51 PM, JS wrote:
> 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?
> because I have better things to do

Implying that our time is of lesser value than yours does not help sell your ideas :-)

On Saturday, 3 August 2013 at 21:42:00 UTC, Walter Bright wrote:
> On 8/3/2013 12:51 PM, JS wrote:
>> 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?
>> because I have better things to do
>
> Implying that our time is of lesser value than yours does not help sell your ideas :-)

No, you guys have a vested interest in D and are the owners who make the final say so... All I can do is present an argument and watch it get shot down.

The only real solution for me is to develop my own language and compilers... But I neither have the time nor the intelligence to do so(at least to do something worthwhile).

But nonetheless, there are certain fundamental properties in language design. I believe that a compilers ONLY goal is to make life easier for the programmer. Hence "short form" is key to this when it does not obfuscate.

I think using the criteria that only denies features that are useful to only a few programmers is very short sighted.

The reason C++ is better than C is because of it's feature set. Stuff like i++(short form) is ONLY for convenience... yet every uses it! NOT because they used it before it exists(obviously) but because the language supported it and then people were able to see how useful it is(and some things take a long time.


Basically "How the hell do you know if something is going to be useful to programmers if the language doesn't support it"? The answer? You don't! But you can get a good idea if what you are asking for is a generalization of something.

If X is a generalization of Y and Y is used then chances are X will be used at some point when people are able to grasp what it does.

For example, what I am proposing is analogous to class inheritance. You have a standard base class(the current switch statement) and a derived class(my extension of the switch). We can use the derived class anywhere we use the base class(we can use the standard switch statement even if we have the ability to use the extended version).

Derivation is always good because it is backwards compatible(conceptually). My switch statement extension is fully backwards compatible with the original. Hence, in no way does it break current usage, so no one can get upset it broke their program. But it makes the language more robust, easier to understand in some cases(but not less in any), and is orthogonal to all other language features(so very little maintenance issues/unintended consequences).

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

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

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

So, you have better things to do, but other people are lazy if they do not implement something you need but they don't?

It's a proof of concept, you offer it to other users (if you build it they will come, or not) who, if they find it as useful as you apparently do will lobby on your behalf.

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

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

It's not true that it has no bearing on anything else.

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

You have the source code for the compiler at your disposal. If this is as trivial to implement, and as useful to you, as you claim, then I do not see why you cannot knock something together to showcase the feature. Are you unwilling to do any work to see this feature implemented? If so, how can you impugn the work ethic of someone (by implying that they ate lazy), who has already donated their time and toil to you, if they follow suit?

Language design is by necessity a conservative affair; it's easy for a language to die a death-by-a-thousand-features.

See if you can find some real-world examples of where this pattern could be useful.

At the very least you need to specify the construct in more detail addressing, for example, the following:
- Does it only work on "final switch" or any switch?
- How are non-integer expressions handled, if at all?
- How does it interpret 'default'?
- How does it deal with range gaps?
- ...

On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
> Um, it can actually save a lot of type and errors.
>
> having two places to change is very error prone.
>
> if (cond) { }
> switch(cond)

What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable:

auto cond = complexCond;
if (cond) { }
switch(cond)...

On Sunday, 4 August 2013 at 01:57:04 UTC, JS wrote:
> Stuff like i++(short form) is ONLY for convenience... yet every uses it! NOT because they used it before it exists(obviously) but because the language supported it and then people were able to see how useful it is(and some things take a long time.

IIRC post/pre-increment/decrement syntax wasn't introduced in C for peoples convenience, it was there to allow naive compilers to use the then faster increment instructions.

On Saturday, 3 August 2013 at 20:38:37 UTC, bearophile wrote:
> 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

You pique my interest. What is this? Looks like template shorthand? I didn't find nything about it in docs. Could you share some links about this?

On Sunday, 4 August 2013 at 15:32:17 UTC, monarch_dodra wrote:
> You pique my interest. What is this? Looks like template shorthand? I didn't find nything about it in docs. Could you share some links about this?

http://wiki.dlang.org/DIP42

On Sunday, 4 August 2013 at 10:14:50 UTC, Kagamin wrote:
> On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
>> Um, it can actually save a lot of type and errors.
>>
>> having two places to change is very error prone.
>>
>> if (cond) { }
>> switch(cond)
>
> What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable:
>
> auto cond = complexCond;
> if (cond) { }
> switch(cond)...

There is also a subtle, but in my opinion important, distinction between the expressions accepted by 'if' and 'switch'.

With 'if' the expression must evaluate to boolean, whereas with 'switch' the expression evaluates to an integral or {w|d}char[] type. With a 'switch' the condition is completed in the 'case'.

Taking an example from

int number;
string message;
switch (number)
{
	default: // valid: ends with 'throw'
	throw new Exception("unknown number");
	case 3:
		message ~= "three "; break;
	case 4:
		message ~= "four "; continue;
	case 5:
		message ~= "five "; goto case;
	case 6:
		message ~= "six "; break;
	case 1:
	case 2:
		message = "one or two";
 }

On Sunday, 4 August 2013 at 15:57:32 UTC, Andre Artus wrote:
> On Sunday, 4 August 2013 at 10:14:50 UTC, Kagamin wrote:
>> On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
>>> Um, it can actually save a lot of type and errors.
>>>
>>> having two places to change is very error prone.
>>>
>>> if (cond) { }
>>> switch(cond)
>>
>> What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable:
>>
>> auto cond = complexCond;
>> if (cond) { }
>> switch(cond)...
>
> There is also a subtle, but in my opinion important, distinction between the expressions accepted by 'if' and 'switch'.
>
> With 'if' the expression must evaluate to boolean, whereas with 'switch' the expression evaluates to an integral or {w|d}char[] type. With a 'switch' the condition is completed in the 'case'.

Oops. I think I hit spacebar twice and the message was posted before I finished it.

Taking an example from the D language reference,

>
> int number;
> string message;
> switch (number)
> {
> 	default: // valid: ends with 'throw'
> 	throw new Exception("unknown number");
> 	case 3:
> 		message ~= "three "; break;
> 	case 4:
> 		message ~= "four "; continue;
> 	case 5:
> 		message ~= "five "; goto case;
> 	case 6:
> 		message ~= "six "; break;
> 	case 1:
> 	case 2:
> 		message = "one or two";
>  }

With the inclusion of 'default' the condition covers the whole range of 'int'. The programmer may only want the pre  and post code to be executed for every other case (1..6).

switch (number)
{
	default: // valid: ends with 'throw'
		throw new Exception("unknown number");
	case 3:
		message ~= "three ";
		break;
	case 5:
		message ~= "five ";
		goto case;
	case 6:
		message ~= "six ";
		break;
	case 2:
		message = "one or two";
 }

Here the range is interrupted, but covered by 'default'. What does the compiler do here?

Sorry I have to go make supper now, but I have a lot more to say on this.

On Sunday, 4 August 2013 at 16:16:25 UTC, Andre Artus wrote:
> On Sunday, 4 August 2013 at 15:57:32 UTC, Andre Artus wrote:
>> On Sunday, 4 August 2013 at 10:14:50 UTC, Kagamin wrote:
>>> On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
>>>> Um, it can actually save a lot of type and errors.
>>>>
>>>> having two places to change is very error prone.
>>>>
>>>> if (cond) { }
>>>> switch(cond)
>>>
>>> What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable:
>>>
>>> auto cond = complexCond;
>>> if (cond) { }
>>> switch(cond)...
>>
>> There is also a subtle, but in my opinion important, distinction between the expressions accepted by 'if' and 'switch'.
>>
>> With 'if' the expression must evaluate to boolean, whereas with 'switch' the expression evaluates to an integral or {w|d}char[] type. With a 'switch' the condition is completed in the 'case'.
>
> Oops. I think I hit spacebar twice and the message was posted before I finished it.
>
> Taking an example from the D language reference,
>
>>
>> int number;
>> string message;
>> switch (number)
>> {
>> 	default: // valid: ends with 'throw'
>> 	throw new Exception("unknown number");
>> 	case 3:
>> 		message ~= "three "; break;
>> 	case 4:
>> 		message ~= "four "; continue;
>> 	case 5:
>> 		message ~= "five "; goto case;
>> 	case 6:
>> 		message ~= "six "; break;
>> 	case 1:
>> 	case 2:
>> 		message = "one or two";
>> }
>
> With the inclusion of 'default' the condition covers the whole range of 'int'. The programmer may only want the pre  and post code to be executed for every other case (1..6).


Like I said, it would be nice if we could extend some D features without change the compiler source, maybe like macros in LISP.

The switch statement should have an event handler like: onBeforeMatch or onAfterMatch to handle this.

But for what I saw on this thread, this is only possible changing the compiler source. :/

Matheus.