Template constraints error messages using cputs()

BCS none at anon.com
Sun Aug 8 12:20:10 PDT 2010

Hello bearophile,

> 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.

Understood, and I see it's value. I'm not going to argue for not having ctputs() 
but I want (need?) a way to have the other option. I don't think these can 
be combined (but I could be wrong).  Just as a point to consider; it might 
be reasonable to implement ctputs in terms of a combination of a compile 
time only puts and a runtime only puts. Either the runtime/compile time version 
or the compile time only version can be derived from the other but deriving 
the former seems cleaner than deriving the latter.

> 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.

Good. We agree.

> 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 :-)

Souinds like a good way to go.

... <IXOYE><

More information about the Digitalmars-d mailing list