Switch: Case Range Syntax

[Andrei Alexandrescu]

On 8/18/11 6:42 AM, Jacob Carlborg wrote:
> On 2011-08-18 00:51, Andrei Alexandrescu wrote:
>> On 8/17/11 2:35 PM, Jacob Carlborg wrote:
>>> D should have a built-in range type. One that supports syntax for both
>>> including and excluding the last element:
>>>
>>> auto a = 3 .. 5
>>> auto b = 3 ... 5
>>>
>>> Then we wouldn't need a special range syntax for switch statements. You
>>> could store ranges in variables and pass them to functions. opSlice
>>> probably wouldn't be needed, instead opIndex could be used and you would
>>> declare the method to take a range instead of two integers.
>>
>> I doubt that would work well. Let's ignore for now mundane issues such
>> as the ambiguity of 3...5 and focus on something like:
>
> I'm just hoping that floating point syntax will be removed. I know a lot
> of people agree with me on this.
>
>> int x;
>> ...
>> switch (x) {
>> case 3 ... 5: return 1;
>> default: return 0;
>> }
>>
>> We'd need to change the behavior of switch anyway, or we'd need to
>> define equality such that e.g. 4 == 3 ... 5. But then equality is not
>> transitive anymore because 4 == 2 ... 6 too, but 3 ... 5 is not equal to
>> 2 ... 6.
>
> There could be some kind of "include" function/property or similar. Just
> as there are built-in properties on other types in D.

There could be indeed a lot of things. My point is that there _need_ to 
be such. It's not a simple, minute addition.

>> Adding new built-in types is not easy. For a variety of reasons we
>> should move the other way (per e.g. the hashtables discussion
>> elsethread).
>>
>>
>> Andrei
>
> I know that the implementation of the associative arrays have been moved
> to the runtime, if you're referring to that. But the compiler still
> knows about the associative array, right? I don't care where a range
> type would be implemented, in the compiler or in the runtime.

I'm not talking about an implementation difficulty, but about semantics 
difficulties within the language. My point is that although the feature 
superficially looks easy to add and nice to have, in reality there are a 
lot of subtle additional changes we must make to the language semantics.

Andrei