• Manu (25/25) Dec 10 2018 So, I know people have studied this, but I can't find any evidence of
• Stefan Koch (16/48) Dec 11 2018 Alright, let me answer those first, once newCTFE lands and runs

Manu <turkeyman gmail.com> writes:

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?

Stefan Koch <uplink.coder googlemail.com> writes:

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