No CTFE of function

[Cecil Ward via Digitalmars-d-learn]

On Saturday, 26 August 2017 at 18:16:07 UTC, ag0aep6g wrote:
> On Saturday, 26 August 2017 at 16:52:36 UTC, Cecil Ward wrote:
>> Any ideas as to why GDC might just refuse to do CTFE on 
>> compile-time-known inputs in a truly pure situation?
>
> That's not how CTFE works. CTFE only kicks in when the *result* 
> is required at compile time. For example, when you assign it to 
> an enum. The inputs must be known at compile time, and the 
> interpreter will refuse to go on when you try something impure. 
> But those things don't trigger CTFE.
>
> The compiler may choose to precompute any constant expression, 
> but that's an optimization (constant folding), not CTFE.

I think I understand, but I'm not sure. I should have explained 
properly. I suspect what I should have said was that I was 
expecting an _optimisation_ and I didn't see it. I thought that a 
specific instance of a call to my pure function that has all 
compile-time-known arguments would just produce generated code 
that returned an explicit constant that is worked out by CTFE 
calculation, replacing the actual code for the general function 
entirely. So for example

     auto foo() { return bar( 2, 3 ); }

(where bar is strongly pure and completely CTFE-able) should have 
been replaced by generated x64 code looking exactly literally like
     auto foo() { return 5; }
expect that the returned result would be a fixed-length literal 
array of 32-but numbers in my case (no dynamic arrays anywhere, 
these I believe potentially involve RTL calls and the allocator 
internally).