Compile time function execution...

[Michiel]

Walter Bright wrote:

>>> Many functions could be executed at compile time, but should not be.
>>
>> When should they not be?
> 
> 1) Another poster mentioned a function that decompressed a built-in
> string - the whole point of having it compressed was to reduce the exe
> file size. Decompressing it at compile time defeats the purpose.

Yes, that one was mentioned by Bill Baxter. But I think this is the
exception rather than the rule. The programmer could explicitly tell the
compiler to not execute that piece of code at runtime.

> 2) A function that simply takes too long at compile time. Compile time
> execution is going to be >100 times slower than run time.

If I'm compiling for release, I wouldn't mind letting the compiler run a
long time if it results in a faster executable.

> 3) As the spec mentions, there are cases where compile time would get
> different results than run time.

It shouldn't, though, should it?

I'm just talking about a possible ultimate goal here. I understand if D
isn't at that stage yet.

> 4) The compiler cannot determine in advance if a function can be
> executed at compile time. So speculatively doing so would have to be
> done for every function with constant arguments - this could be
> spectacularly slow.

Like I said, I wouldn't mind. As long as it doesn't take that long when
I'm debug-mode compiling. I don't need compile time execution in that case.

> 5) It can cause problems for people who want to do runtime coverage
> testing - their code may actually never get executed, and they never
> notice.

Nothing a compiler-switch can't fix, I think.

-- 
Michiel