Array Slice Ranges

Ary Manzana ary at esperanto.org.ar
Thu Nov 9 06:42:04 PST 2006


rm escribió:
> Ary Manzana wrote:
>> Mike Parker escribió:
>>> Alexander Panek wrote:
>>>> I'd really like to have a distinction between exclusive and 
>>>> inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or 
>>>> similar, with '..' => '..-'. Not *that* beautiful, though .. maybe 
>>>> someone has a better suggestion.
>>>>
>>>
>>> What about leaving ... as is and using ..+, or ...+, for inclusive?
>>
>> I think the best approach is to use standard mathematical notation:
>>
>> array[1 .. 5] == 1, 2, 3, 4, 5
>> array(1 .. 5] == 2, 3, 4, 5
>> array[1 .. 5) == 1, 2, 3, 4
>> array(1 .. 5) == 2, 3, 4
>>
>> There's no confusion there when you know mathematical ranges. The only 
>> problem is it's a confusion to the compiler... maybe?
> 
> well if compiler issues are no issues, than the most explicit would be:
> 
> array[1 .. 5] == 1,2,3,4,5
> array]1 .. 5] ==   2,3,4,5
> array[1 .. 5[ == 1,2,3,4
> array]1 .. 5[ ==   2,3,4
> 
> roel

Very nice!!

The problem with "array(1 .. 5)" is it could look like a method call. 
But I guess the compiler could peak past the first expression after the 
'(' to see if it's a "..", so then it's a range expression. With 
"array]1 .. 5[" the compiler inmediately knows it's a range expression.

But I don't know if yours is the most explicit. In mathematics the 
parenthesis is used to exclude a number in a range, not the inverted 
bracket.

Anyway, it would be *great* if any of this is implemented. This way we 
benefit from two things:
- More expressiveness in the language.
- You don't have to remember that "[1 .. 5]" actually means "1, 2, 3, 4" 
(at first glance it looks like "1, 2, 3, 4, 5" to me), which could lead 
to bugs.

"opSlice" should be called in any of the four cases, the compiler should 
choose the appropiate value to send to the method depending on the 
brackets/parenthesis used, but "opSplice" should be aware that the first 
number is inclusive, the last is exclusive (just like now). Changing 
this convention could break a lot of old code.



More information about the Digitalmars-d mailing list