www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - constexpr and CTFE

reply bearophile <bearophileHUGS lycos.com> writes:
This first question is mostly for D.learn, but below I show a partially related
link too, so I put both of them here.

If you have library code, and the users of your library run one of your
functions at compile time, later if you change your function it may not run at
compile time any more. So isn't the quality of being able to run at compile
time part of the signature of the function?

---------------

GCC 4.6 implements the C++0x constexpr. I've found a note about constexpr, that
touches the topic of logic const too, purity, memoization:

http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr-capability-in-c0x/4750253#4750253

Bye,
bearophile
Mar 27 2011
next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

 This first question is mostly for D.learn, but below I show a partially
 related link too, so I put both of them here.
 
 If you have library code, and the users of your library run one of your
 functions at compile time, later if you change your function it may not
 run at compile time any more. So isn't the quality of being able to run at
 compile time part of the signature of the function?

An attribute similar to pure that can be checked by the compiler might be useful. However, the signature affects the type right? I'm not sure that is the intent of ctfe. A simple ddoc annotation and a unittest is probably enough to both ensure and convey the ctfe-ability.
 ---------------
 
 GCC 4.6 implements the C++0x constexpr. I've found a note about constexpr,
 that touches the topic of logic const too, purity, memoization:
 
 http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr-

 
 Bye,
 bearophile

Mar 27 2011
prev sibling parent so <so so.so> writes:
On Sun, 27 Mar 2011 17:50:00 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 This first question is mostly for D.learn, but below I show a partially  
 related link too, so I put both of them here.

 If you have library code, and the users of your library run one of your  
 functions at compile time, later if you change your function it may not  
 run at compile time any more. So isn't the quality of being able to run  
 at compile time part of the signature of the function?

 ---------------

 GCC 4.6 implements the C++0x constexpr. I've found a note about  
 constexpr, that touches the topic of logic const too, purity,  
 memoization:

 http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr-capability-in-c0x/4750253#4750253

 Bye,
 bearophile

constexpr is a primitive utility comparing to D, and why it is designed the way it is in C++ is IMO nothing but to maintain backwards compatibility, not because it has anything over what we have here. enum ctfe = fun(); If "fun" no longer ctfe'able compiler will output and error and that is all we need. Why would a library designer care if his code will be executed at compile or runtime? No reason i can think of.
Mar 29 2011