It seems possible that we can print CTFE variables at compile
time by using string mixes as the code below demonstrates.
The problem is that we can not pass a variable to a template to
create a print routine in the first place. e.g., we can't do
mixin a!(s) if s is a string since s can't be read, supposedly,
at compile time.
We can't even do mixin("mixin a!(\""~s~"\");") though to get
around this.
The following code at least proves that CTFE variables can be
read at compile time and the limitation is with the internal
implementation.
(this is easy to see, because on one hand we can't print s but on
the other we can... hence the limitation with pragma is an
artificial one.)
import std.stdio, std.cstream, std.conv;
mixin template a()
{
template b()
{
static string c()
{
string s = "a"; s ~= "b";
string x = "pragma(msg, \""~s~"\");";
// pragma(msg, s) // fails
return x;
}
enum b = c();
}
mixin(b!());
}
int main(string[] argv)
{
mixin a!(); // can't pass a string to a in any way because of
artificial ctfe limitation
din.getc();
return 0;
}

It seems possible that we can print CTFE variables at compile
time by using string mixes as the code below demonstrates.
The problem is that we can not pass a variable to a template to
create a print routine in the first place. e.g., we can't do
mixin a!(s) if s is a string since s can't be read, supposedly,
at compile time.

I think there's been mention a couple times of a ctfeWrite
function that can print values at compile-time, but so far
nobody's implemented it.

I think there's been mention a couple times of a ctfeWrite
function that can print values at compile-time, but so far
nobody's implemented it.

That's not true. This is the ER:
http://d.puremagic.com/issues/show_bug.cgi?id=3952
And the patch:
https://github.com/D-Programming-Language/dmd/pull/237
A significant problem with GitHub is that it's managed mostly as
as a LIFO (last in first out), it means the last added patches
get exposure, are discussed, and they often get added to the
code. But if they are not merged in few weeks, they get out of
radar and they get forgotten, and they rot for years. This is a
significant problem for D development that so far doesn't have a
solution. I don't remember Andrei or Walter every discussing
about this problem or proposing solutions...
Bye,
bearophile

A significant problem with GitHub is that it's managed mostly
as as a LIFO (last in first out), it means the last added
patches get exposure, are discussed, and they often get added
to the code. But if they are not merged in few weeks, they get
out of radar and they get forgotten, and they rot for years.
This is a significant problem for D development that so far
doesn't have a solution. I don't remember Andrei or Walter
every discussing about this problem or proposing solutions...

Although that's a problem, it's not at all what's happened here.
That patch would not have worked, essentially because it mixes
values-inside-CTFE with literals-outside-CTFE. It worked in
simple cases, but not in general. That's not a simple problem
with the patch that could have been fixed at the time.

It seems possible that we can print CTFE variables at compile
time by using string mixes as the code below demonstrates.
The problem is that we can not pass a variable to a template
to create a print routine in the first place. e.g., we can't
do mixin a!(s) if s is a string since s can't be read,
supposedly, at compile time.

I think there's been mention a couple times of a ctfeWrite
function that can print values at compile-time, but so far
nobody's implemented it.

I've heard of this too and even tried __ctfeWrite and it worked!!
Well, at least no compile time error... just didn't print
anything.
I believe the error "variable can't be read at compile time" is
due to the fact that the compiler doesn't have access to/isn't
aware of the frame pointers(the stack) of the functions. This
means that "local" variables can't be used in compile time,
before ctfe, constructs because there is no way to get at the
data.
This seems like a limitation of the system and not some innate
reason why it should fail...

It seems possible that we can print CTFE variables at compile
time by using string mixes as the code below demonstrates.
The problem is that we can not pass a variable to a template
to create a print routine in the first place. e.g., we can't
do mixin a!(s) if s is a string since s can't be read,
supposedly, at compile time.

I think there's been mention a couple times of a ctfeWrite
function that can print values at compile-time, but so far
nobody's implemented it.

I've heard of this too and even tried __ctfeWrite and it worked!!
Well, at least no compile time error... just didn't print
anything.
I believe the error "variable can't be read at compile time" is
due to the fact that the compiler doesn't have access to/isn't
aware of the frame pointers(the stack) of the functions. This
means that "local" variables can't be used in compile time,
before ctfe, constructs because there is no way to get at the
data.
This seems like a limitation of the system and not some innate
reason why it should fail...

Making it work would be like trying to make an if function as a static if. It
would muddle things considerably and as such is a very bad idea IMHO. Right
now, there is a very clean distinction between what's done at compile time and
what's done at runtime as well as between CTFE and templated code. Allowing
what you're trying to do would ruin that.
- Jonathan M Davis