Just another example of missing string interpolation

[Adam D Ruppe]

On Wednesday, 18 October 2023 at 03:57:52 UTC, Walter Bright 
wrote:
> What does writeln() do with __header?

"The __header value, to be discussed later, is generated by the 
compiler and contains compile-time information about the 
interpolated string."

<a few moments later>

"The header object has a trivial toString method that expands to 
the null string. This method makes it possible to pass 
interpolated strings directly to functions such as writeln and 
text because these functions detect and use toString to convert 
unknown data types to strings."

It just uses the existing rules for a struct. No special case 
here. It doesn't spell this out, but you can think about what 
happens to normal D functions if you pass some `struct` to a 
function expecting a `string` - an ordinary type mismatch error. 
This is what gives library authors such power with this proposal: 
they can overload a function to provided specialized behavior.

Which brings me to:

> I think we're misunderstanding each other. What I am asking 
> about is how does the user specify his own custom 
> implementation of InterpolatedExpression?

There's no need. You just pass it to a function.

Library authors overload functions on the type of what was 
passed, including an interpolated type if desired, same as any 
other overload. End users call a particular function uses the 
given arguments to create their desired result; a generic 
function forwarder still works, preserving the full interpolated 
argument, since it works like any other set of function arguments.

This gives *enormous* capability to both sides - mostly by using 
already existing features in the D language.