On 09/28/2011 03:33 PM, Christophe wrote:
Jonathan M Davis , dans le message (digitalmars.D:145520), a écrit :
foreach (i; 1 .. BigInt(10)) {}
BigInt isn't going to work with the .. syntax regardless of what
isIntegral does.
It makes some time that I think the .. syntax should be improved.
I wanted to make a post about that but I have done it yet.
First, Range are such a part of the langage now that I think 0..10
deserves to be a Range, and not a syntax sugar for opSlice and foreach.
It could be a type called int..int that behaves like iota!(int, int),
and .. be an operator that takes for example two ints and return an
int..int(*).
| auto OpSlice(size_t, size_t);
could be renamed
| auto OpIndex(size_t..size_t);
and we could also make overloads for multidimensional arrays:
| auto OpIndex(size_t..size_t, size_t..size_t);
which is IMHO much more meaningful and satisfying than:
| auto OpIndex(size_t, size_t, size_t, size_t);
or
| auto OpSlice(size_t[2], size_t[2]);
People might say this makes the langage more complicated, because we
create a new type in the language. I think on the contrary that this
makes the language simpler: it unifies foreach(i; 1..n),
opSlice(size_t, size_t), opIndex (and iota in many cases).
This would probably be a breaking language change, because currently
'..' has no operator precedence associated with it (it is just a
delimiter token, much like ';').
@Topic: In practice, I have never felt the need to use BigInt's as
foreach iterator variables. What is the use for such a feature?
I mean, eg. the following is hardly useful:
foreach(i;0..BigInt("10000000000000000000000000"){}
