On Sunday, 27 August 2017 at 00:08:45 UTC, Jonathan M Davis wrote:
> [...]

Indeed. I used the term CTFE too loosely.

On Monday, 28 August 2017 at 03:16:24 UTC, Mike Parker wrote:
> On Sunday, 27 August 2017 at 17:47:54 UTC, Cecil Ward wrote:
>> [...]
>
> The rules for CTFE are outlined in the docs [1]. What is described there is all there is to it. If those criteria are not met, the function cannot be executed at compile time. More importantly, as mentioned earlier in the thread, CTFE will only occur if a function *must* be executed at compile time, i.e. it is in a context where the result of the function is required at compile-time. An enum declaration is such a situation, a variable initialization is not.
>
> [...]

Those links are extremely useful. Many thanks. Because I am full of NHS pain drugs, I am pretty confused half the time, and so finding documentation is difficult for me through the haze, so much appreciated. RTFM of course applies as always.

On Saturday, 26 August 2017 at 16:52:36 UTC, Cecil Ward wrote:
> I have a pure function that has constant inputs, known at compile-time, contains no funny stuff internally - looked at the generated code, and no RTL calls at all. But in a test call with constant literal values (arrays initialised to literal) passed to the pure routine GDC refuses to CTFE the whole thing, as I would expect it (based on previous experience with d and GDC) to simply generate a trivial function that puts out a block of CTFE-evaluated constant data corresponding to the input.
>
> Unfortunately it's a bit too long to post in here. I've tried lots of variations. Function is marked nogc safe pure nothrow
>
> Any ideas as to why GDC might just refuse to do CTFE on compile-time-known inputs in a truly pure situation? Haven't tried DMD yet. Can try LDC. Am using d.godbolt.org to look at the result, as I don't have a machine here to run a d compiler on.
>
> Other things I can think of. Contains function-in-a-function calls, which are all unlined out in the generated code nicely, and not the first time I've done that with GDC either.
>
> Switches: Am using -Os or -O2 or -O3 - tried all. Tuning to presume + enable the latest x86-64 instructions. release build, no bounds-checks.

I will henceforth use the enum trick advice all times.

I noticed that the problem with init =void is compiler-dependent. Using an enum for real CTFE, I don't get error messages from LDC or GDC (i.e. [old?] versions currently up on d.godbolt.org) x64 compilers even if I do use the =void optimisation. This saved a totally wasteful and pointless zero-fill of 64 bytes using 2 YMM instructions in the particular unit test case I had, but of course could easily be dramatically bad news depending on the array size I am unnecessarily filling.