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-

Jason House wrote:
> Walter Bright Wrote:
> 
>> のしいか (noshiika) wrote:
>>> 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 think this was hashed out ad nauseum in the n.g.
> 
> 
> Hardly. There seemed to mostly be complaints about it with Andrei saying things like "I can't believe you don't see the elegance of the syntax".

There's been also suggestions of inferior syntax, as are now.

Andrei

bearophile wrote:
> Jason House:
>> Hardly. There seemed to mostly be complaints about it with Andrei saying things like "I can't believe you don't see the elegance of the syntax". In the end, Andrei commented that he shouldn't involve the community in such small changes and went silent.<
> 
> He was wrong. Even very intelligent people now and then do the wrong thing.

Of course the latter statement is true, but is in no way evidence supporting the former. About the former, in that particular case I was right.

Andrei

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?

Andrei

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.

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). You can find other "ugly" things by looking at repetitive mails to this newsgroup.

Also, there's a limitation of just 256 cases. What's that? Where that limitation come from? That looks week.

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

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.

Derek Parnell wrote:
> Safety is supposed to be enhance by using D, is it not?

See my post to Denis. Requiring too many casts reduces safety by essentially disabling the static type checking system.

grauzone wrote:
> Walter Bright wrote:
>> のしいか (noshiika) wrote:
>>> But I am a bit disappointed with the CaseRangeStatement syntax.
>>> Why is it
>>>    case 0: .. case 9:
>>> instead of
>>>    case 0 .. 9:
> 
> Or
>     case [0..10]:
> ?
> 
> Compatible to how list slicing works.
> 
> Ah yes, bikeshed issue, but my solution is more beautiful.

No, it isn't compatible. [0..10] for slices does not include the 10, while the case range does. Using Andrei's syntax clearly makes the point that it is different, and not confusingly similar to something very different.

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