"Andrei Alexandrescu" <[email protected]> wrote in message news:[email protected]... > Nick Sabalausky wrote: >> "Walter Bright" <[email protected]> wrote in message >> news:[email protected]... >>> 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 ;) )
