dmd 1.046 and 2.031 releases

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:h2udmf$1b0c$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
>> news:h2u735$sn8$1 at 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 ;) )