So, I know people have studied this, but I can't find any evidence of
concise collated data.
I don't know how to implement CT range logic efficiently.
There are 3 competing strategues:
- recursive template expansion (including staticMap)
- static foreach, which may require a fail-test suffix if no iteration
of the loop assigned the template
- CTFE foreach

Which is preferable, and for what counts of elements?
I think conventional wisdom is that CTFE is always superior? Is that
true? *always*?
Is there any CTFE overhead on small datasets (ie, 0-2 elements).
Is there overhead in the case where you might need to coerce a tuple
into a runtime array for looping on by surrounding it in `[ tup ]`?

What about static foreach? Is it superior to CTFE foreach in the limited places where it's applicable, but where either could be chosen?

We need reliable best-practises.

On a tangent, I think D would really benefit from C++11's `...`
expression; which applies a static-map in-language without any
recursive template expansions or other workarounds, and with a much
improved readability.
That expression could replace basically every application of static
operation on lists extremely efficiently... has it been rejected
already? Why?

On Tuesday, 11 December 2018 at 06:15:45 UTC, Manu wrote:
> So, I know people have studied this, but I can't find any evidence of
> concise collated data.
> I don't know how to implement CT range logic efficiently.
> There are 3 competing strategues:
> - recursive template expansion (including staticMap)
> - static foreach, which may require a fail-test suffix if no iteration
> of the loop assigned the template
> - CTFE foreach
>
> Which is preferable, and for what counts of elements?
> I think conventional wisdom is that CTFE is always superior? Is that
> true? *always*?
> Is there any CTFE overhead on small datasets (ie, 0-2 elements).
> Is there overhead in the case where you might need to coerce a tuple
> into a runtime array for looping on by surrounding it in `[ tup ]`?

Alright, let me answer those first, once newCTFE lands and runs with it's own x86 jit, it _will_ be the fastest path. Except for verly simple loops with up to 5 iterations, where the jit overhead will dominate, however even in that case the overhead will be very small, compared to the alternatives.

> What about static foreach? Is it superior to CTFE foreach in the limited places where it's applicable, but where either could be chosen?

static foreach is genrally slow, and without clever decision logic and proper integration with newCTFE it is very likely that it won't improve.
However when iterating over type-tuples it is pretty much the only option.

> We need reliable best-practises.
>
> On a tangent, I think D would really benefit from C++11's `...`
> expression; which applies a static-map in-language without any
> recursive template expansions or other workarounds, and with a much
> improved readability.
> That expression could replace basically every application of static
> operation on lists extremely efficiently... has it been rejected
> already? Why?

one reason could be that ... expressions look ugly.
And as soon as newCTFE lands the performance problems will not be an issue.

Regards,

Stefan