New operators opStaticIndex and friends

[Q. Schroll]

On Tuesday, 14 May 2019 at 17:27:25 UTC, angel wrote:
> You say:
> int i = s[0]; // rewrites to s.opStaticIndex!(0), as 0 can be
> int j = s[i]; // rewrites to s.opIndex(i), as i cannot be read 
> at compile-time
>
> But actually, in this example, s[i] CAN be figured out at 
> compile-time.

You get it wrong: The fact that `i` can be figured out by some 
clever compiler is irrelevant. You couldn't assign it to some 
static immutable or enum. You couldn't use it as a template 
parameter. This is not about clever optimizations, it is about 
wether the spec says, the value is present at compile time.

> What is even more problematic is that the ability of the 
> compiler to figure out the value of 'i' and s[i] at 
> compile-time might depend on the optimization level, thus you 
> cannot be sure whether s.opStaticIndex!(1) or s.opIndex(i) will 
> be called.
>
> IMHO, s[0] is already calculated in compile-time when 
> appropriate optimization level is invoked ... at least it 
> should've been.

If `seq` is a non-empty AliasSeq, you can use seq[0]. You cannot 
use seq[i] for `i` defined as above. The spec says that `i`'s 
value is determined at runtime, i.e. when the compiled program is 
executed. If the compiler's optimizer can figure out that it 
knows the value beforehand, it won't make the thing compile.

When talking about language specification, one rarely considers 
optimizations.