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.

Reply via email to