It seems pure ain't so pure after all

[Timon Gehr]

On 10/01/2012 08:02 PM, foobar wrote:
> On Monday, 1 October 2012 at 17:46:00 UTC, Tommi wrote:
>> On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
>>> And you _can't_ determine ahead of time which functions can be safely
>>> executed at compile time either, because that's an
>>> instance of the halting problem.
>>
>> I don't understand (I did read what "halting problem" means just now,
>> but I still don't understand). If there was no __ctfe variable, and
>> thus a guarantee that all functions do the same thing at compile-time
>> and run-time, couldn't the compiler just try aggressively to execute
>> all function calls at compile-time? Obviously it wouldn't bother
>> trying CTFE for function calls that had arguments which weren't
>> evaluable at compile-time. Nor would it bother with functions that it
>> knows have memory allocations or other limitations of CTFE.
>>
>> If not a compiler flag, then it could be a function attribute. Just
>> like c++ function attribute constexpr, which guarantees that the
>> function executes at compile time given you provide it with
>> compile-time evaluable arguments (and there are limitations to what
>> the function can do). Why wouldn't this attribute be possible with D?
>
> __ctfe is a horrible yet very useful hack to address the underlying
> issue - the execution model for CTFE, which I personally do not agree
> with. Adding a compiler flag for the existing model, makes no sense
> whatsoever. Functions are essentially a run-time abstraction and the
> compiler generally speaking has no business trying to execute them at
> compile-time. The compiler is after all *not* an interpreter.
>

A D compiler is also a D interpreter. I wouldn't even bother with D if 
this wasn't the case.

> Besides, what would be the use case for such a flag anyway? If you
> already know that all parameters are known at compile-time, you can
> already "tell" the compiler to execute the function by assigning to a
> static/enum variable.
>
> IMO, this mixing of code for various stages of execution is bad design
> but this cannot be changed in a backwards compatible way.