Bug 3952d: __ctfeWriteln

[kennytm]

Make DMD recognize the __ctfeWriteln function at interpret-time, and print the arguments to console when used.

Note: dlang/druntime#52 need to be pulled as well.

For example, the code

bool x() {
  foreach (i; 0 .. 4)
    __ctfeWriteln(i, "^^2 == ", i*i);
  return true;
}
enum _ = x();

will print

0^^2 == 0
1^^2 == 1
2^^2 == 4
3^^2 == 9

when compiling.

This is not a replacement of pragma(msg).

---

(BTW, Phobos's writeln can still behave like #237 by adding a CTFE version:

void writeln(T...)(T x) {
      if (__ctfe)
        __ctfeWriteln(x);
      else
        stdout.write(x, '\n');
}

)

[dnadlinger]

+1 from me, this is certainly helpful for debugging CTFE functions and tracing down CTFE bugs.

However, I still don't get why there is no __ctfeWrite that doesn't automatically append a newline. I'd even argue that there only the latter should be a magic function, as __ctfeWriteln can easily be implemented in terms of it as a normal CTFEable function, but not the other way round.

[mrmonday]

@klickverbot:

 Error: some error here
 message without newlineError: some other erroranothermessage from ctfewrite

As you can see, it makes it hard to find errors. Plus, if its sole purpose is for debugging, this ought to be fine. If you need a write then I guess you'd have to use a buffer of some sort.

[dnadlinger]

@mrmonday: Obviously, you have to be careful about including newlines at the right places, but what is especially hard to do within the boundaries of CTFE? Right, keeping state (e.g. a buffer for collecting non-newline messages) without explicitly passing it around to all involved parties.

And especially when a feature is used only for debugging purposes, I'd argue that it should be flexible enough to be just thrown in at some place in for some debugging output, not the other way round.

Another reason why I think restricting CTFE output to including newlines is not the best idea is because at least in my experience, CTFE especially lends itself to functional-style recursive algorithms, where processing of a single entity is spread across a number of function calls, and thus adding a buffer to avoid the automatically appended newline would require temporary modifications to several function signatures.

To wrap it up, I just don't get why we should want to introduce a completely artificial, hard to work around limitation, just for … whatever real reasons there are for it anyway. Yes, of course, in many cases you want your debugging output to be terminated by a newline anyway, but especially in cases where the user cannot easily avoid them an alternative, I think we should think twice about the motivations before putting restrictions into place.

Concerning the example output you posted (there probably would be a newline after »some other error«, btw), this problem could be easily avoided by the compiler forcing a newline before writing an error message, or if the output of __ctfeWrite is written to the standard output, by the user redirecting stdout to /dev/null and only looking at stderr.

[yebblies]

This pull request cannot be automerged. (A friendly reminder!)

[kennytm]

Superseded by #692.