A Philosophy of Software Design

H. S. Teoh hsteoh at qfbox.info
Mon May 25 14:29:33 UTC 2026


On Sun, May 24, 2026 at 11:36:17PM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/24/2026 5:47 PM, H. S. Teoh wrote:
[...]
> > On a more serious note, I find D's .writefln a much better debugging
> > tool than C's printf.
> 
> You're right, but my issue with writefln is even a simple call to it
> generates and absolute blizzard of template code emitted to the object
> file.  Since much of my work involves looking at the assembler dump of
> the code, it becomes hard to find what I'm looking for in that
> blizzard.

The current implementation of writefln leaves a lot of room for
improvement.  A single call with a simple "%s" format pulls in the
machinery for a truckload of specialized formatting code, like
floating-point formatting (which like all things IEEE is exceedingly
complex), BigInt handling, ad nauseum.

Retrospect is always 20/20, as they say, but what *should* have been
done is that the format string should be a compile-time argument that's
scanned at compile-time by CTFE, and transformed into a series of
straightforward calls for each argument.  For example, writing:

```
	writefln("Value at (%d, %d) is %.02f", x, y, price);
```

should generate the equivalent of:

```
	writeln("Value at (");
	writeln(formatInt(x));
	writeln(", ");
	writeln(formatInt(y));
	writeln(") is ");
	writeln(formatFloat(price);
```

I.e., it should only pull in what's actually used, not the entire
formatting subsystem for handling every conceivable D type.


> I've discussed this with Adam (Phobos2) and he agrees and will address
> it.

Let's hope it will not be another over-engineered solution.


T

-- 
Every time you make a typo, the errorists win.


More information about the Digitalmars-d mailing list