• bearophile (7/7) Mar 27 2011 This first question is mostly for D.learn, but below I show a partially ...
• Lutger Blijdestijn (7/23) Mar 27 2011 An attribute similar to pure that can be checked by the compiler might b...
• so (10/23) Mar 29 2011 constexpr is a primitive utility comparing to D, and why it is designed ...

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:



Bye,
bearophile

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

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:



 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.