https://issues.dlang.org/show_bug.cgi?id=16302

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #1 from Steven Schveighoffer <schveiguy@yahoo.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=16302

Danila Letunovskiy <kapblc@mail.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kapblc@mail.ru

--- Comment #2 from Danila Letunovskiy <kapblc@mail.ru> ---
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"){
}

--

https://issues.dlang.org/show_bug.cgi?id=16302

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=16302

--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=16302

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
(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!

--

https://issues.dlang.org/show_bug.cgi?id=16302

Yuxuan Shui <yshuiv7@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yshuiv7@gmail.com

--- Comment #6 from Yuxuan Shui <yshuiv7@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=16302

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=16302

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qs.il.paperinik@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=16302

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

--