On Mon, 06 Jul 2009 14:12:40 +0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Denis Koroskin wrote:
>> Does it compare on case-by-case basis? Up to 256 comparisons?
>
> What do you mean? Obj2asm will show what it is doing.

I mean, will it translate

switch (i) {
    case 0:
    ..
    case 9:
       doSomething();
}

into

if (i == 0 || i == 1 || i == 2 || etc) doSomething();

or into

if (i >=0 || i <= 9) doSomething();

Denis Koroskin wrote:
> On Mon, 06 Jul 2009 14:12:40 +0400, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> Denis Koroskin wrote:
>>> Does it compare on case-by-case basis? Up to 256 comparisons?
>>
>> What do you mean? Obj2asm will show what it is doing.
> 
> I mean, will it translate
> 
> switch (i) {
>     case 0:
>     ..
>     case 9:
>        doSomething();
> }
> 
> into
> 
> if (i == 0 || i == 1 || i == 2 || etc) doSomething();
> 
> or into
> 
> if (i >=0 || i <= 9) doSomething();

I'm sure it translate it to:

case 0:
case 1:
case 2:
case 3:
case 4:
case 5:
case 6:
case 7:
case 8:
case 9:

That's obvious from the "maximum of 256 cases allowed".

And also you can see that in the source code. :)

Statement *CaseRangeStatement::semantic(Scope *sc)
...
/* This works by replacing the CaseRange with an array of Case's.
 *
 * case a: .. case b: s;
 *    =>
 * case a:
 *   [...]
 * case b:
 *   s;
 */

Reply to Walter,

> Ary Borenszweig wrote:
> 
>> Walter Bright escribio':
>> 
>>> MIURA Masahiro wrote:
>>> 
>>>> Thanks for the new release!  Are case ranges limited to 256 cases?
>>>> 
>>> Yes.
>>> 
>> Why?
>> 
> To avoid dealing with it in the back end for the moment. The back end
> will die if you pass it 3,000,000 case statements :-)
> 

I get your point. OTOH I rather suspect the back end will die if you give it 3,000,000 of just about anything. 

Andrei Alexandrescu wrote:
> Ary Borenszweig wrote:
>> Andrei Alexandrescu wrote:
>>> Ary Borenszweig wrote:
>>>> のしいか (noshiika) escribió:
>>>>> Thank you for the great work, Walter and all the other contributors.
>>>>>
>>>>> But I am a bit disappointed with the CaseRangeStatement syntax.
>>>>> Why is it
>>>>>    case 0: .. case 9:
>>>>> instead of
>>>>>    case 0 .. 9:
>>>>>
>>>>> With the latter notation, ranges can be easily used together with
>>>>> commas, for example:
>>>>>    case 0, 2 .. 4, 6 .. 9:
>>>>>
>>>>> And CaseRangeStatement, being inconsistent with other syntaxes
>>>>> using the .. operator, i.e. slicing and ForeachRangeStatement,
>>>>> includes the endpoint.
>>>>> Shouldn't D make use of another operator to express ranges that
>>>>> include the endpoints as Ruby or Perl6 does?
>>>>
>>>> I agree.
>>>>
>>>> I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.
>>>
>>> And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards?
>>
>> They probably used an if.
> 
> So they used an inferior means to start with.
> 
>> But I think it's not about that. If D didn't have the possibility to define case range statements, it would be better. Now there's a possibility to do that, but with an ugly syntax (you'll find out when this newsgroup will receive about one or two complaints about this each month, not to mention there were already a lot of complaints).
> 
> This is speculation. And the complaints usually were accompanied with inferior suggestions for "improving" things. Everyone wanted to add some incomprehensible, inconsistent, or confusing syntax to do ranged cases, as long as it wasn't the one I'd chosen.
> 
>> You can find other "ugly" things by looking at repetitive mails to this newsgroup.
> 
> I and others don't find the added syntax ugly in the least.
> 
>> Also, there's a limitation of just 256 cases. What's that? Where that limitation come from? That looks week.
> 
> That's just an implementation limitation that future versions will eliminate.
> 
> 
> Andrei

Shoving is the way.  Pushing is inferior.

Walter Bright wrote:
> grauzone wrote:
>> No. Also, this final switch feature seems to be only marginally useful, and normal switch statements do the same, just at runtime. So much for "more pressing issues" but it's his language and not mine so I'll shut up.
> 
> The final switch deals with a problem where you add an enum member in one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch.
> 
> It's solving a similar problem that symbolic constants do.
> 
> 
> The fall-through thing, though, is purely local and so much less of an issue.

huh?

These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs.

They are that evil kind of bug where you can stare at the exact lines of code that cause it and remain completely clueless until the epiphany hits.  This is no good, unless the compiler can be rewritten to induce epiphanies.


"much less of an issue"
T_T

On Mon, 6 Jul 2009 15:03:20 +0000 (UTC), BCS wrote:

> Hello Derek,
> 
>> The -deps= switch is helpful, but can we also have a "-nogen" switch so that a compile is done but no object files are created.
> 
> look at: -o-

Thanks, I've never noticed that switch before. Excellent.

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

Chad J wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> No. Also, this final switch feature seems to be only marginally
>>> useful, and normal switch statements do the same, just at runtime. So
>>> much for "more pressing issues" but it's his language and not mine so
>>> I'll shut up.
>> The final switch deals with a problem where you add an enum member in
>> one file and then have to find and update every switch statement that
>> uses that enum. There's no straightforward way to find them to ensure
>> the case gets added to each switch.
>>
>> It's solving a similar problem that symbolic constants do.
>>
>>
>> The fall-through thing, though, is purely local and so much less of an
>> issue.
> 
> huh?
> 
> These bugs always take me no less than 2 hours to find, unless I am
> specifically looking for fall-through bugs.

I agree. Probably a good option would be to keep on requiring break, but
also requiring the user to explicitly specify they want fallthrough in
the rare case when they do want it. I'd love to use "continue" for that
but it's already "occupied" by cases like while (...) switch (...).
Requiring !break or ~break would work but is a bit too cute. Adding a
new keyword or a whole new switch statement is too much aggravation. I
guess we'll have to live with it...


Andrei

Walter Bright wrote:
> Denis Koroskin wrote:
>> I'd put an assert and mad a case explicit, if there is a size_t is so badly needed for ptr difference:
>>
>> assert(p1 >= p2);
>> size_t y = cast(size_t)p1 - p2;
> 
> Aside from the typo in that code (!) the problem with casts is they are a sledgehammer approach. Casts should be minimized because they *hide* typing problems in the code. The more casts in the code, the more the type-checking abilities of the compiler are disabled. I suspect this will *hide* more bugs than it reveals.
> 
> The reality is is that most integers used in programs are positive and relatively small. int and uint are equally correct for these, and people tend to use both in a mish-mash. Trying to build a barrier between them that requires explicit casting to overcome is going to require a lot of casts that accomplish nothing other than satisfying a nagging, annoying compiler.
> 
> I've used such a compiler - Pascal back in the early 80s. All the casts
> it required me to insert basically sucked (and never revealed a single
> bug). When I discovered C with its sensible system of implicit casting,
> it was like putting on dry clothes after being soaked out in the cold rain.

In the context of a sign-sensitive language

assert(p1 >= p2);
size_t y = cast(size_t)p1 - p2;

looks to me like it is equivalent to

size_t y = p1 - p2;

but in the context of a sign-insensitive language.

The difference in behavior is that the former has a runtime assert, which is arguably useful.  The difference in aesthetics/maintainability is that the former has that undesirable cast in there.

Perhaps we can have the best of both worlds, and just make the latter work but automatically insert the given runtime assert while in debug/non-release mode.

So in D2 the code

size_t y = p1 - p2;

would become

assert(p1 >= p2);
size_t y = p1 - p2;

during compilation.

Sure having negative indices around would eventually crash the program anyways, but it's really helpful to have the program crash as close to the bug's location as possible.

(Also not seeing that typo.  dmd seems to think it's alright syntactically, and don't we want p1 to be greater?)

Reply to Chad,

> Walter Bright wrote:
> 
>> The fall-through thing, though, is purely local and so much less of
>> an issue.
>> 
> huh?
> 
> These bugs always take me no less than 2 hours to find, unless I am
> specifically looking for fall-through bugs.
> 
> They are that evil kind of bug where you can stare at the exact lines
> of code that cause it and remain completely clueless until the
> epiphany hits.  This is no good, unless the compiler can be rewritten
> to induce epiphanies.
> 
> "much less of an issue"
> T_T

The much worse class of bugs is the ones that you can be staring at the location of the bug, have an epiphany about what the bug is and still not be able to tell if it is the case: the bug is here, but cause by a line of code that could be anywhere.

On Mon, 06 Jul 2009 22:48:07 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Chad J wrote:
>> Walter Bright wrote:
>>> grauzone wrote:
>>>> No. Also, this final switch feature seems to be only marginally
>>>> useful, and normal switch statements do the same, just at runtime. So
>>>> much for "more pressing issues" but it's his language and not mine so
>>>> I'll shut up.
>>> The final switch deals with a problem where you add an enum member in
>>> one file and then have to find and update every switch statement that
>>> uses that enum. There's no straightforward way to find them to ensure
>>> the case gets added to each switch.
>>>
>>> It's solving a similar problem that symbolic constants do.
>>>
>>>
>>> The fall-through thing, though, is purely local and so much less of an
>>> issue.
>>  huh?
>>  These bugs always take me no less than 2 hours to find, unless I am
>> specifically looking for fall-through bugs.
>
> I agree. Probably a good option would be to keep on requiring break, but
> also requiring the user to explicitly specify they want fallthrough in
> the rare case when they do want it. I'd love to use "continue" for that
> but it's already "occupied" by cases like while (...) switch (...).
> Requiring !break or ~break would work but is a bit too cute. Adding a
> new keyword or a whole new switch statement is too much aggravation. I
> guess we'll have to live with it...
>
>
> Andrei

Reuse goto?