A Philosophy of Software Design

[Richard (Rikki) Andrew Cattermole]

On 26/05/2026 2:29 AM, H. S. Teoh wrote:
> 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.

There is a simple way to archive this, use IES.

Give IES support for format strings, and a lot of these problems 
disappear. Not to mention we can kill off the entire f variants!

But alas politics...