Wanted to implement a RefTuple which keeps pointers to elements inside, and allows tuple[index] to return a different type for each index, while converting an internally-stored pointer to a result ref.
However, opIndex currently takes only runtime indices.
I suggest having:
x[i]
where 'i' is a compile-time value, compile to:
x.opStaticIndex!i() and if this fails to resolve to a method, fall back to x.opIndex(i) (similar to the way foreach method resolution uses fallbacks from opApply to range interface).
Of course if 'i' is a run-time value, it compiles to x.opIndex(i) as before.
The compiler could disallow defining both an opStaticIndex and an opIndex simultaneously to guarantee saner behavior:
int x = 1;
enum y = 1;
assert(foo[x] == foo[y]);
This makes tuples less magical, and allows enriching the library with interesting tuple-like types.
Comment #1 by schveiguy — 2016-07-20T13:08:25Z
Yes, I would love this too. At this point the only way to get compile-time indexing is by alias this-ing an AliasSeq, as std.typecons.Tuple does.
There's other interesting things, opStaticIndex could accept any type as the index.
Comment #2 by kapblc — 2016-07-20T20:15:54Z
Yeah and opStaticBinary and opStaticAssign and opStaticEquals ;D
struct Enum(T) {
T n;
opStaticAssign(string s)(){ return n = s.to!T; }
opStaticEqual(string s)(){ return n == s.to!T; }
}
enum Color { red, green, blue }
Enum!Color c = "red";
if(c == "red"){
}
Comment #3 by bugzilla — 2017-05-12T16:40:26Z
This is an intriguing idea, but it is a significant change to the language and so a DIP (D Improvement Proposal) is merited. The DIP needs to present a rationale, compelling use cases, and existing workarounds.
It may seem like a lot of work, but Andrei recently presented a DIP for contextual imports, much discussion ensued, and then a member of the community pointed out that it could be easily done with existing features. The DIP was happily withdrawn.
It's important that we exhaust opportunities for finding such capability within the existing language.
Comment #4 by schveiguy — 2017-05-12T21:20:05Z
I really would like to see this, and it's pretty straightforward how it would look, so I will write a DIP to see if there is interest.
Comment #5 by bugzilla — 2017-05-12T22:12:26Z
(In reply to Steven Schveighoffer from comment #4)
> I really would like to see this, and it's pretty straightforward how it
> would look, so I will write a DIP to see if there is interest.
Great!
Comment #6 by yshuiv7 — 2017-05-13T04:13:39Z
(In reply to Steven Schveighoffer from comment #4)
> I really would like to see this, and it's pretty straightforward how it
> would look, so I will write a DIP to see if there is interest.
I want to suggest we just reuse opIndex. If opIndex is defined as a template, the static semantic is used.
Comment #7 by schveiguy — 2017-05-13T17:12:53Z
(In reply to Yuxuan Shui from comment #6)
> I want to suggest we just reuse opIndex. If opIndex is defined as a
> template, the static semantic is used.
This is a good idea.
s[arg1, arg2] is lowered to opIndex(arg1, arg2)
the compiler could try opIndex!(arg1, arg2) if it applies, otherwise fall back on the normal opIndex.
Where I am concerned is the case where runtime indexing accepts template parameters. However, in those cases, the template parameters must all be types, and implied via IFTI, meaning it has runtime parameters that match each type.
The static opIndex needs to have zero runtime parameters ALWAYS. I think it still can work.
I'd like to continue having the slice usage that is so flexible in the current implementation at compile-time as well.
Comment #8 by robert.schadek — 2024-12-13T18:49:01Z