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

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

Am 08.08.2010 17:41, schrieb 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.
>
> 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 see the need for ctputs-like construct but I don't like the name. What about simply making puts magically ctfe-able. The runtime behavior is clearly defined and the compiler has to to simply catch calls to the real puts when ctfe-ing and replace it with it's implemantation.
What do you, bearophile and others, think?

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

Mafi:
> I see the need for ctputs-like construct but I don't like the name. What
> about simply making puts magically ctfe-able. The runtime behavior is
> clearly defined and the compiler has to to simply catch calls to the
> real puts when ctfe-ing and replace it with it's implemantation.
> What do you, bearophile and others, think?

If that can be done, then I am OK with that too.

Bye,
bearophile