On Mon, 25 Apr 2011 22:44:07 +0300, bearophile <[email protected]>
wrote:
This is a possible enhancement request for DMD. I am not sure about the
consequences of this, so this is currently not in Bugzilla, I look for
opinions.
DMD currently runs functions at compile time only if their call is in a
context where a compile-time value is expected, to avoid troubles. C++0X
uses a keyword to avoid those problems.
constexpr double pi = 3; // C++
enum double pi = 3; // D
constexpr double fun() { return 3; } // C++
double fun() { return 3; } // D
For variable declaration, exact same thing.
For functions, i am not exactly sure the need for a keyword and i think
the D way is simply beautiful and truly generic.
One reason i could think of is for library development, you sometimes want
to be sure that a function "could be" executed at compile-time. In C++
there is no such thing i am aware of, in D we got unittesting.
[-----------------
Little box:
Time ago I have heard that "enum" is useless and const/immutable
suffice. So if "enum" gets removed from D how do you tell apart the
desire to run a function (not a global call) at compile time from the
desire to run it at run time and assign its result to a run-time
constant value?
int bar(int x) {
return x;
}
void main() {
enum b1 = bar(10); // runs at compile-time
const b2 = bar(20); // doesn't run at compile-time
}
Another question is why would the left hand side of "=" even matter? What
is wrong with executing the function(constant) pair always at compile-time
(if it could be executed that is)? Only reason using "enum, static,
immutable" over "auto" should be "making sure" it runs at compile-time
(again, if it can).
Obviously we know the reasons for the desire for compile-time execution,
is there any reason at all for runtime?
