New operators opStaticIndex and friends

[Ahmet Sait]

On Tuesday, 14 May 2019 at 18:35:51 UTC, H. S. Teoh wrote:
> On Tue, May 14, 2019 at 06:13:18PM +0000, Ahmet Sait via 
> Digitalmars-d wrote:
>> On Tuesday, 14 May 2019 at 15:49:51 UTC, Q. Schroll wrote:
>> > I whish, D has these operators:
>> > 
>> > opStaticIndex
>> > opStaticIndexAssign
>> > opStaticIndexOpAssign
>> > opStaticSlice
>> 
>> I think this is solving the wrong problem. If compiler 
>> provided means to check whether a parameter is known at 
>> compile time easily & consistently these would not be 
>> necessary at all. Of course, talk is cheap and actually 
>> implementing such new __traits is rather compilcated.
>
> Again, people are getting confused by the overloaded term 
> "compile-time". People really need to read this:
>
> 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
> (Sorry for the shameless self-plug.)
>
> opStaticIndex is necessary because it pertains to the *AST 
> manipulation* phase of compilation, whereas opIndex pertains 
> the executable phase (CTFE and/or runtime).  It's meaningless 
> to "check whether a parameter is known at compile time" because 
> you cannot go back to the AST manipulation stage after you have 
> passed semantic analysis, which is when types are resolved and 
> things like VRP are applied.
>
>
> T

I've read it before, and read it again now just to be sure. 
Obviously such functions (the ones that check whether a variable 
is known at CT) need to be templates and get instantiated on 
every call to actually work.

Something close to this:

auto opIndex()(size_t i)
{
     enum types = [ "double", "long", "int" ];
     static if (__traits(isKnownAtCT, i))
     {
         static if (i < types.length)
             return mixin("cast(" ~ types[i] ~ ")i");
         else
             return "Here be dragons";
     }
}