Mixed int/BigInt foreach interval

[Christophe]

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).

-- 
Christophe

(*) Notes:
- compose type like char..int should be forbidden in a way. In 
char a; a..1000, the char a should be promoted to int to make an 
int..int.

- the .. operator could be overloaded for types like BigInt, like normal 
binary operator overloads. This overload may returned a user-defined 
type (that we ask to be a Range), or, alternatively, the langage could 
allow to have a BigInt..BigInt type, with the library being able to 
overload operations (empty, front, popFront, etc) on BigInt..BigInt like 
we can do for arrays (like: popFront(BigInt..BigInt r) { r[0] = r[0] + 
1; } ).