Switch: Case Range Syntax

[Jacob Carlborg]

On 2011-08-18 15:36, Andrei Alexandrescu wrote:
> 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

Ok, we can stop this discussion. In my original post I was just trying 
to say that it's a pity that D doesn't have a built-in range type and if 
it was three, four years ago it could have been added to the language, 
perhaps. I could have avoided a few, in my opinion, "hacks", like the 
case ranges. I fully understand if this feature cannot be added to the 
language now.

-- 
/Jacob Carlborg