On Mon, 06 Jul 2009 14:38:53 -0500, Andrei Alexandrescu wrote:

> Denis Koroskin wrote:
>> Reuse goto?
> 
> So any case-labeled code should end either with a control flow statement that transfers control elswhere? That sounds like a great idea. Fall-through is so rare and so rarely intended, it makes sense to require the programmer to state the intent explicitly via a goto case.
> 
> Andrei

The goto method already works, the only change needed would be to not have fallthru default.

http://digitalmars.com/d/2.0/statement.html#GotoStatement

Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:h2u735$sn8$1@digitalmars.com...
>> grauzone wrote:
>>> I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y).
>> It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive.
>>
> 
> The current way has that inconsistency:
> 
> variable .. variable   // exclusive end
> caseLabel .. caseLabel    // inclusive end
> 
> And yes, I know that's not how it's actually parsed, but that's how people visually parse it.

I don't think so at all. There's a lot of punctuation that has different roles depending on the context. For example, ":" means key/value separator or ternary operator participant; "*" means multiplication or pointer dereference; "&" means taking address or binary "and"... plenty of examples. So you can't center on ".." and claim that it visually means the same thing even though the surrounding is different. You really have no argument here.

> Ah the hell with it, I don't care any more: The *real* issue here is that the current switch, being based on C's, is horribly antiquated and what we really need is a comprehensive redesign incorporating some sort of generalized pattern matching. Like "case > 1, <= 10:" or something like Nemerle, or whatever. I don't care, as long as it doesn't continue to get trivialized as something that can be solved by tossing in a recycled ".." here, a recycled "final" there, etc. 

On the full side of the glass, with the latest dmd release, the language has acquired some useful feature improvements and the implementation has fixed many bugs. Why the crankiness?


Andrei

Jesse Phillips escribió:
> On Mon, 06 Jul 2009 14:38:53 -0500, Andrei Alexandrescu wrote:
> 
>> Denis Koroskin wrote:
>>> Reuse goto?
>> So any case-labeled code should end either with a control flow statement
>> that transfers control elswhere? That sounds like a great idea.
>> Fall-through is so rare and so rarely intended, it makes sense to
>> require the programmer to state the intent explicitly via a goto case.
>>
>> Andrei
> 
> The goto method already works, the only change needed would be to not have fallthru default.
> 
> http://digitalmars.com/d/2.0/statement.html#GotoStatement

But that's kind of redundant:

case 1: goto case 11:
case 11: goto case 111:
case 111: goto case 1111:
case 1111:
	doIt();

don't you think?

If you change the case expression, you must change it twice.

Why not:

case 1: continue case;
case 11: continue case;

etc.?

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:h2udmf$1b0c$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:h2u735$sn8$1@digitalmars.com...
>>> grauzone wrote:
>>>> I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y).
>>> It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive.
>>>
>>
>> The current way has that inconsistency:
>>
>> variable .. variable   // exclusive end
>> caseLabel .. caseLabel    // inclusive end
>>
>> And yes, I know that's not how it's actually parsed, but that's how people visually parse it.
>
> I don't think so at all. There's a lot of punctuation that has different roles depending on the context. For example, ":" means key/value separator or ternary operator participant; "*" means multiplication or pointer dereference; "&" means taking address or binary "and"... plenty of examples. So you can't center on ".." and claim that it visually means the same thing even though the surrounding is different. You really have no argument here.
>

Those examples are all cases where the meaning and context are wildly different fbetween one use and the other. But with '..', both uses are very similar: "From xxx to (incl/excl) yyy". Big differences are ok, they stand out as obvious. Small differences can be more problematic.

FWIW, Even though I dislike it, I don't think it's a sky-falling issue or anything. I just don't think it's so "obviously great" as you and Walter see it. Basically, I see it as a questionable *but* acceptable solution *provided that* it's just a stop-gap in the interim before finally getting a completely re-thought switch/pattern-matcher.

>> Ah the hell with it, I don't care any more: The *real* issue here is that the current switch, being based on C's, is horribly antiquated and what we really need is a comprehensive redesign incorporating some sort of generalized pattern matching. Like "case > 1, <= 10:" or something like Nemerle, or whatever. I don't care, as long as it doesn't continue to get trivialized as something that can be solved by tossing in a recycled ".." here, a recycled "final" there, etc.
>
> On the full side of the glass, with the latest dmd release, the language has acquired some useful feature improvements and the implementation has fixed many bugs. Why the crankiness?
>

Because it's really hot in this room right now... ;)  But seriously though, it's just this issue I'm cranky about. I can absolutely agree there's been a lot of good changes. (Although I would really love to see my patch for #2567 incorporated...*squeak**squeak* says the wheel ;) )

On Mon, 06 Jul 2009 21:59:54 -0500, Andrei Alexandrescu wrote:

> There's a lot of punctuation that has different roles depending on the context.

Agreed. No argument here. The meaning of punctuation depends on its context. Got it.

However, that aside, the syntax you have chosen will have a rational explanation for its superiority. So can you explain in simple terms why

    CaseLabelInt .. CaseLabelInt  eg. case 1: .. case 9:

is superior than

    case CaseRange:  eg. case 1 .. 9:

given that
  CaseLabelInt ==> case IntegerExpression :
  CaseRange    ==> IntegerExpression .. IntegerExpression

> On the full side of the glass, with the latest dmd release, the language has acquired some useful feature improvements and the implementation has fixed many bugs.

Yes it truly has, and thank you very much to all contributors.

> Why the crankiness?

Because it is so demoralizing to point out 'warts' in D/DMD and be subsequently dismissed as ungrateful plebeians who are wasting the time of the patricians. Sorry, but you did ask.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Hello Ary,

> But that's kind of redundant:
> 
> case 1: goto case 11:
> case 11: goto case 111:
> case 111: goto case 1111:
> case 1111:
> doIt();
> don't you think?
> 

case 1, 11, 111, 1111:
doIt();

> If you change the case expression, you must change it twice.
> 
> Why not:
> 
> case 1: continue case;
> case 11: continue case;
> etc.?
> 

Or how about the way c# does it: consecutive cases are treated as a single target. For that matter, it's debatable if going from one case label to an immediately following one even constitutes a fall through considering they are attached to the following statement rater than being statements in there own right.

Derek Parnell wrote:
> However, that aside, the syntax you have chosen will have a rational
> explanation for its superiority. So can you explain in simple terms why 
> 
>     CaseLabelInt .. CaseLabelInt  eg. case 1: .. case 9:
> 
> is superior than
> 
>     case CaseRange:  eg. case 1 .. 9:
> 
> given that
>   CaseLabelInt ==> case IntegerExpression :
>   CaseRange    ==> IntegerExpression .. IntegerExpression


Because

1.	case X..Y:

looks like

2.	foreach(e; X..Y)
3.	array[X..Y]

yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y.

Having a very different meaning means it should have a distinctly different syntax.

Andrei Alexandrescu wrote:
> I agree there are ugly constructs in D, and is-expressions would near the top of the list (particularly the absolutely awful is(T : T[])), but you have no case (heh) with the switch statement.
> 
> 
> Andrei

Just a funny suggestion: could we change the is() expression to imperative style?

Now:
template Something(T, U, V) if ( is(T : T[]) && is(...) )
{
     alias T blah1;
     U blah2;
     class C {};
     struct S {};
}

In mirror universe:
template Something(T, U, V)
in
{
    static if ( T : T[] ) // static if here mean if (is (...))
    {
       // may do something with T, make alias, change type
       // or check another constraint.
    }
    else
    {
        pragma(msg, "T must be Klingon");
        static assert(false); // Or return false; ????
    }

    static if ( U == int )
    {
       V = float; // ?????
    }
    return true;
}
body
{
     alias T blah1;
     U blah2;
     class C {};
     struct S {};
}

On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Something for everyone here.
>
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.046.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.031.zip

Thanks for another great release.

Also, I'm not sure if this is a bug or a feature with regard to the new integer rules:

   byte x,y,z;
   z = x+y;    // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to byte

which makes sense, in that a byte can overflow, but also doesn't make sense, since integer behaviour is different.

BTW: The fact that in my original code base DMD gave me the line, inside the string, inside the mixin, inside the template, inside the mixin, inside the struct was just awesome.

P.S. There's a bunch of functions in phobos (like std.math.lrint) which return a long and should also have (at least) an integer version as well. (Maybe rndto!T() ?)

Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:h2udmf$1b0c$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:h2u735$sn8$1@digitalmars.com...
>>>> grauzone wrote:
>>>>> I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y).
>>>> It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive.
>>>>
>>> The current way has that inconsistency:
>>>
>>> variable .. variable   // exclusive end
>>> caseLabel .. caseLabel    // inclusive end
>>>
>>> And yes, I know that's not how it's actually parsed, but that's how people visually parse it.
>> I don't think so at all. There's a lot of punctuation that has different roles depending on the context. For example, ":" means key/value separator or ternary operator participant; "*" means multiplication or pointer dereference; "&" means taking address or binary "and"... plenty of examples. So you can't center on ".." and claim that it visually means the same thing even though the surrounding is different. You really have no argument here.
>>
> 
> Those examples are all cases where the meaning and context are wildly different fbetween one use and the other. But with '..', both uses are very similar: "From xxx to (incl/excl) yyy". Big differences are ok, they stand out as obvious. Small differences can be more problematic.

You'd have an uphill battle using a counterfeit Swiss army knife against a battery of Gatling guns arguing that

case 'a': .. case 'z':

is very similar with

0 .. 10

That's actually much more different than e.g.

a = b * c;

versus

b * c;

> FWIW, Even though I dislike it, I don't think it's a sky-falling issue or anything. I just don't think it's so "obviously great" as you and Walter see it.

I'm not claiming it's obviously great. I do claim it's highly appropriate.

> Basically, I see it as a questionable *but* acceptable solution *provided that* it's just a stop-gap in the interim before finally getting a completely re-thought switch/pattern-matcher.

What is the question you are asking in the "questionable" part?


Andrei