bug in pragma?

[JS]

On Thursday, 4 July 2013 at 23:06:39 UTC, Jonathan M Davis wrote:
> On Friday, July 05, 2013 00:48:49 JS wrote:
>> This is simply wrong. If s could not be used at compile time 
>> then
>> the mixin could not be used at compile time... yet it can be 
>> and
>> is being used and works fine when the pragma is removed... and
>> one can even pragma the template name after the function and it
>> will work.
>
> You're misunderstanding the difference between CTFE and stuff 
> that has to be
> known at compile time. A function called with CTFE must be 
> callable like any
> other function at runtime. There's nothing special about it. It 
> can be called
> at compile time, but there can't be anything about its 
> implementation which
> requires it to be called at compile time. The only reason that 
> the function is
> even being called at compile time is because it's being used to 
> initialize an
> enum.
>
> Contrast this with the value of an enum, which _must_ be known 
> at compile
> time.
>
> - Jonathan m Davis

It shouldn't matter that string can behave as a runtime or 
compile time construct. The fact is, if it's used at compile time 
it has compile time behavior and pragma should have no issues 
with it.

Just because a function *can be* used a run time doesn't mean 
that when it is used at compile time it has be limited.

My guess is it has to do with the evaluation order. pragma and 
lower level compile time constructs get precedence and never get 
to see higher level constructs like strings(almost surely because 
these higher level constructs were created after the fact).

But there is no apriori reason why a compile time string can't be 
used in compile time functions. (regardless if a compile time 
string can also be used as a runtime string... since it is not)

After all,

what's the semantical difference between

enum s = "a" ~ "b" ~ "c";
enum s = "a"; s ~= "b"; s ~= "c";
string s = "a" ~ "b" ~ "c";
string s = "a"; s ~= "b"; s ~= "c";

Only the first works and is very limiting.

If you want to keep enums then allow them to be modified at 
compile time... since a modification at compile time has nothing 
to do with immutability since it is still immutable at runtime.

that is, enum s = "a"; s ~= "b"; at compile time is not a 
violation of the immutability of an enum.

Basically, come up with a compile time string that has all the 
properties of a string and act like an immutable string at 
runtime. runtime strings can be converted to this new type of 
string when they are used at compile time... but then this just 
results in using the standard d string.

I think it's a logical flaw in D's CTFE system rather than some 
innate reason why it doesn't work.