We currently have the ability to do opIndex for simulating an array or
other type indexed at runtime.
But we have no way to simulate the ability of tuple indexing. Such an
ability would unleash a huge amount of possibilities, including
user-defined tuple types.
Let's designate a straw man name: opTupleIndex.
In essence, if you have foo[n], where n is a compile-time constant, then
opTupleIndex would be instantiated (if defined) like:
opTupleIndex!n
Then you can have user-defined tuples that are simple to define:
struct KeyValuePair(K, V)
{
K key;
V value;
enum length = 2;
ref K opTupleIndex(int x) if(x == 0) { return key;}
ref V opTupleIndex(int x) if(x == 1) { return value;}
}
auto x = KeyValuePair!(int, string)(1, "hi");
static assert(typeof(x[0]) == int);
static assert(typeof(x[1]) == string);
x[0] = 4;
x[1] = "hi";
Note here I have all the mechanisms that real tuples have, but I have
control over what happens when accessing each element, and I do not need
opIndex to change its return type based on a runtime parameter (one of
the limitations of the current system).
I'm not huge on tuple usage, so I'm not sure if I'm missing something.
Currently there is some debate as to whether to add a "byPair" range to
builtin AAs, because the return value from 'front' is hard to define.
This might go a long way in helping such a case.
Does this sound like something worth having? We likely would have to
error if both opIndex and opTupleIndex are defined for a specific type.
-Steve
