Bug 1924 – Allow writefln like ouput during CTFE.

char[] wrongfunc() { char[] result; pragma(msg, result); // fail at this line return result; } mixin(wrongfunc);

Your 'result' is a variable that happens not to get assigned at runtime, but the fact that it happens not to change doesn't mean it's a constant. P.S. According to the spec it even needs to be a string literal (which I don't think is what the compiler implements, since I'm pretty sure it allows string constants constructed by templates and ctfe). But either way your code is clearly illegal.

char[] wrongfunc() { char[] result="void main()"; result ~= "{}"; const char[] myresult= result; pragma(msg, myresult); // fail at this line return result; } mixin(wrongfunc); abc.d(6): Error: string expected for message, not 'result' pragma here is clearly for debugging CTFE. I don't want to make it as the following char[] getresult() { char[] result="void main()"; result ~= "{}"; return result; } char[] myfunc() { const char[] result = getresult(); pragma(msg,result); return result; } mixin(myfunc); it's way dummier for debugging CTFE, especially if i want to do only some simple inspect on some particular vars.

Although a way of debugging CTFE functions would be very nice to have, this is definitely not a bug. I'm changing this to an enhancement, changed title from: fail to pragma compile time constant

I think we need separate notation for this. Generating a compiler message while compiling a function is conceptually different from generating a compiler message while evaluating it.

pragma(writefln,"hello #%d", 1); vote++;

From the names pragma(msg) and pragma(writefln), it isn't clear at all that one's while compiling and one's while evaluating. Better would be to name it something like "ctfeMsg" or "msgCTFE". And perhaps writefln notation could be supported in both this and regular msg. This won't break existing code as long as pragma(msg, string) with no further arguments is still defined to write that exact string.

To date, every use of writefln I've seen has been run time. So it doesn't seem particularly ambiguous at least to me,

(In reply to comment #7) > To date, every use of writefln I've seen has been run time. So it doesn't seem > particularly ambiguous at least to me, That's because at the moment writefln can only be executed at run time. If it (or something resembling it) becomes executable at compile time, it could just as well be either as and when compiled or during CTFE. Having a difference between pragma(msg) and pragma(writefln) beyond what they say on the tin would be arbitrary and confusing.

Sorry, I was far less than clear. writefln in all cases we use it in now executes with the code path, e.g. when the code is executed rather than generated. pragma is compile time in all cases. Seems like a good fit to me. OTOH as long as it's not something like pragma(D9B01F73-E64A-4FA9-A2DE-C20CD24560BA) I'm not going to object to getting it!

On second thoughts, this isn't an actual proposal. There's a genuine need, but pragma(msg) inside CTFE is not the solution. I think we should just kill this bug, and create a new one when there's an actual proposal for how it should work.

Vote++ or rename and re-tag it.

This bug report is invalid. The original reported issue is invalid since pragma cannot evaluate at compile time the value of a runtime variable. As for the other proposed issue - the ability to print when a function is evaluated - it doesn't have to be implemented in the compiler. This can be implemented as a function in phobos. Changing component from dmd to phobos. Test case: import std.stdio; char[] wrongfunc() { char[] result; writeln(result); return result; } void main() { enum c = wrongfunc(); }

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/phobos/issues/9578 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB