Michiel wrote:
> Walter Bright wrote:
>> It's the other way around. Functions are always executed at runtime,
>> unless they are in a context where a compile-time constant is
>> *required*, such as for global variable initialization or template value
>> arguments.
> 
> I know that's how it's implemented now. But generally, it's a good thing
> if as much as possible happens at compile time.

Many functions could be executed at compile time, but should not be. There's NO way for the compiler to figure this out. The only thing left is for it to be explicit whether you want compile or run time execution, and this is the way it is designed. There isn't any ambiguity - the context determines it completely.

There's also an easy way to switch between the two, so I don't feel there's a need for anything additional.

Andrei Alexandrescu (See Website For Email) wrote:
> where $b is a dynamic variable. They just use the uniform syntax and let the compiler do whatever the hell it has to do to generate good code. We should make that kind of partial evaluation easy to define and implement.

I agree.

Walter Bright wrote:

> Many functions could be executed at compile time, but should not be.

When should they not be?

-- 
Michiel

Michiel wrote:
> 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.

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

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

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.

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.

torhu wrote:
> Walter Bright wrote:
>> This should obsolete using templates to compute values at compile time.
> 
> Wonderful feature, but look at this:
> 
> int square(int x)
> {
>    return x * x;
> }
> 
> const int foo = square(5);
> 
> al_id4.d(6): Error: cannot evaluate (square)(5) at compile time
> 
> 
> I was hoping this would make some C macros easier to replace, without needing template versions for initializing consts.

Aggh, that's a compiler bug.

int foo = square(5);

does work. I knew I'd never get it right the first try :-(

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

Reply to Walter,

> Michiel wrote:
> 
>> 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.
> 
> 2) A function that simply takes too long at compile time. Compile time
> execution is going to be >100 times slower than run time.
> 
> 3) As the spec mentions, there are cases where compile time would get
> different results than run time.
> 
> 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.
> 
> 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.
> 

6) when the whole program is const foldable, e.i. no runtime inputs, like with some scientific software.

Andrei Alexandrescu (See Website For Email) wrote:

> Bill Baxter wrote:
>> Walter Bright wrote:
>>> Walter Bright wrote:
>>>> This should obsolete using templates to compute values at compile time.
>>>
>>> For contrast, compare with the C++ proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1972.pdf
>> 
>> It's kinda long and boring, but it looks like the key differences are
>> 
>> 1) The need to tag compile-time functions with a new keyword, "constexpr", though they seem to sell this as an advantage.  "a programmer can state that a function is intended to be used in a constant expression and the compiler can diagnose mistakes." -- page 9.
>> 
>> 2) The restriction that a constexpr function can only contain "return" followed by exactly one expression.  No loops for you!  And I hope you like quadruply nested b?x:y expressions!
> 
> 3) The C++ feature is applicable to user-defined types.
> 
> Andrei

These user-defined literals seem useful too. Would it be hard to implement this with structs, or are there perhaps more subtle issues? Here is an earlier article it was based on: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1511.pdf

Btw this is a really cool feature, how it is done in D I mean. A little while ago someone posted a CachedFunction template to do memoization on any function, this is now easy to do 100% safe, right? Or at least for the subset of functions that pass the compile-time criteria.

BCS wrote:

> 6) when the whole program is const foldable, e.i. no runtime inputs, like with some scientific software.

That's interesting. What kind of program has no runtime inputs?

And why would it be a problem if the whole program is reduced to printing constants to the output? It would certainly be small and fast.

-- 
Michiel

Reply to Michiel,

> BCS wrote:
> 
>> 6) when the whole program is const foldable, e.i. no runtime inputs,
>> like with some scientific software.
>> 
> That's interesting. What kind of program has no runtime inputs?
> 
> And why would it be a problem if the whole program is reduced to
> printing constants to the output? It would certainly be small and
> fast.
> 

I have a program that calculates the number of N length sequences whose sum is less than M. M and N are consts so it has no inputs. Runtime speed is of no more importance than compile time speed because I only need to run it once for each time I compile it. I'd rather let the CPU do the crunching rather than the DMD. It takes about 15min to run as is, so that would be about 1500+ min under DMD.