Foreach Range Statement

[Reiner Pope]

Bill Baxter wrote:
> Don Clugston wrote:
>> I think the convention "first_element .. last_element+1" cannot be 
>> extended to negative and floating-point numbers without creating an 
>> inconsistency. Which is quite unfortunate.

I'm not sure of the problem with negative integers is. Even for negative 
integers x, the identity still holds, that the following two expressions 
are equivalent:

      a <= x
      a <  x+1

But the floating point issue is a bummer. And it's also a bit silly for 
chars. To test whether c is a digit, you would have to write:

    c in ['0'..'9'+1]

which looks a little silly.

> 
> In Python the last_element..first_element inclusive case is handled by 
> omissions.
>   10:0:-1  --- 10 downto 1, inclusive -- doesn't include 0
>   10::-1 --- 10 downto last one - includes 0
> 
> For D I guess that might become
>    10..$:-1
> but $ would have to become something context sensitive, rather than just 
> a synonym for .length.  Which I guess is the same as saying you'd have 
> to introduce an inconsistency, or at least a less strict form of 
> consistency, to the interpretation of $.
> 

To me, it isn't obvious that $==0 in your example. But I think the real 
value of $ is in multi-dimensional arrays, because without it you would 
get something like:

   int[,,] a = ...;
   int[,,] my_slice = a[1..$, 1..$, 1..$];
   int[,,] my_slice_ugly = a[1..a.length[0], 1..a.length[1], 
1..a.length[2]];

To support that, I would use Andrei's suggested grammar, but instead of 
$ translating into a.length, the compiler should first try a.length(0) 
or a.length(1), etc, where the parameter is the parameter number where 
the $ occurs. (It's a hack, I know, but I think it's better than $ 
generating a delegate...)


   -- Reiner