BCS: > All the issues you address up to where you propose ctputs are bugs in DMD, > not pragma(msg,...) as for ctputs as a /replacement/ see my replay to the > bug.
Thank you for this answer and the answer in bugzilla. I explain the problems I find while I program in D, and sometimes I try to give a starting point for a solution, but usually it's not hard to find solutions better than the ones I suggest. I have written an answer in Bugzilla, I don't know if it's enough. > you will not convince me that what it currently does is less than /very > useful/. You are right :-) > My minimum requirements for a pragma(msgm...) replacement would be that it > take any expression that results in an immutable(char[]) and, at compile > time (and only compile time) during the semantic pass (while the code is > processed, not evaluated) output the string. I'd like to ctputs() to act as std.c.stdio.puts() if the function is run at run time. > The major cases where your ctputs fails on this are inside a function that > can be evaluated via CTFE: > - If placed in a RT loop it could be evaluated to many times. > - If placed in a code path that isn't hit via CTFE, it never outputs anything. > - If the function gets run at RT, then you need to add a guard to prevent > it from generating output at RT. This is by design. But I understand your point, ctputs seems designed for a purpose different than pragma(msg), it doesn't seem a replacement. ctputs is meant as a way to print strings from function if you call the function both at runtime or compile time with CTFE. pragma(msg) is meant to show a message at compile time. So pragma(msg) needs to be debugged and then kept. I probably have update the bug report, and I'd like to split it in a pragma(msg) bug report (essentially to make it test its input argument better), plus an enhancement request for a ctputs() probably in std.intrinsic :-) Bye and thank you, bearophile
