It seems pure ain't so pure after all

[Jonathan M Davis]

On Monday, October 01, 2012 23:15:55 Graham Fawcett wrote:
> On Monday, 1 October 2012 at 20:41:53 UTC, Tommi wrote:
> > On Monday, 1 October 2012 at 20:33:29 UTC, Graham Fawcett wrote:
> >> string exclaim(string v)() {
> >> 
> >> return v ~ "!";
> >> 
> >> }
> >> 
> >> void main() {
> >> 
> >> writeln(exclaim!("howdy"));
> >> 
> >> }
> > 
> > It doesn't scale well to have to write both compile-time and
> > run-time versions of your functions.
> 
> And how is your proposed @force_ctfe attribute going to solve
> this issue? If you're forcing CTFE, by definition you don't have
> runtime support.
> 
> As you clearly know, D already supports functions that can run at
> compile-time and run-time: that's the whole point of of CTFE.

If I understand correctly, what he wants is for CTFE to be forced only in 
cases where all of the arguments are known at compile time (e.g. when you pass 
a string literal), so it wouldn't prevent anything from running at runtime.

This would be a complete disaster if it were done in the general case. For 
instance, writeln("hello") can't be executed at compile time, and since the 
only way for the compiler to know that in most cases is to run the function, 
compile times would tank and probably cause other entertaining issues. So, a 
compiler flag like was previously suggested in this thread would be a _very_ 
bad idea.

On the other hand, if a function attribute were introduced where the 
programmer indicated that they wanted that function to execute at compile time 
as long as all of the arguments were known at compile time, that would work 
just fine (as long as it really _could_ be executed at compile time - but we 
already have that issue when assigning the results of functions to enums). The 
question is whether it's worth adding such an attribute to the language, and 
clearly, most of us think that explicitly using enum suffices whereas Tommi 
wants such a function attribute.

- Jonathan M Davis