CTFE writeln again (__ctfeWriteln)

[KennyTM~]

On Aug 9, 11 03:19, bearophile wrote:
> KennyTM~:
>
>> I understand that you could implement `writeln` in terms of `write`, but
>> I question its practical value.   Why do you need to print a tree at
>> compile time?  pragma(msg) and __ctfeWriteln are mainly for debugging,
>> and adding a newline is very suitable (e.g. it won't mess up the error
>> message in the next line).
>
> What if you are debugging a program (as I have written) that uses trees? I'd like the freedom to print textual trees one piece at a time (in Python I have written two or three small programs that print trees textually). It's not just trees, it's also other 2D tables. If you add the newline then I am forced to print one table line at a time, I can't print its items one after the other.
>
> Even if printing at compile-time is mainly for debugging, if you add that newline you make other unexpected future usages harder. You do not know how D will be used ten years from now.
>
> In Python2 there the main printing statement adds a space between printed items. This is quite handy. But what if you do not want that space? Things gets harder. They have had to wait for Python3 to fix this design mistake.
>
> The moral of the Python2 story is that you are allowed to add a handy printing function (that adds newlines and spaces) only if you _also_ have a function that prints nude strings (or nude chars). But if you have only one function, then it has to be a function that doesn't add extra things that you can't remove.
>
> (An alternative design, if you want a single function is a function templated on a boolean __ctfeWrite!(bool newline=true)(...). I don't know how much nice this is).
>
> Bye,
> bearophile

A __ctfeWrite could certainly be added 10 year from now if that's 
required, but at the current stage, I still see no compelling reason for 
that. If you have a tree, probably you'd write a toString() anyway, and 
for a 2D table, you could write a whole row at a time as an array.

     foreach (row; twoDarray) {
       __ctfeWriteln(row);
       ...
     }

Meanwhile, using __ctfeWrite improperly could easily mess up with error 
messages which breaks IDE on locating the line of error.

     1, 2, 3, x.d(55): Error: dereference of null pointer 'null'
     x.d(47): Error: cannot evaluate delegate pure nothrow @system int()

Python's print statement/function is irrelevant. We're not talking about 
printing at runtime where having the possibility to format things pretty 
is essential. Printing things at compile time should always be for 
debugging or error reporting which should be kept simple.

Unless there are more _people_ supporting this, or the authority (those 
who can commit into DMD directly) require having a __ctfeWrite, I'll 
refrain from adding this generalization to D2.