Overhead of DIP1036

[Alexandru Ermicioi]

On Tuesday, 9 January 2024 at 19:05:40 UTC, Walter Bright wrote:
> On 1/9/2024 12:45 AM, Alexandru Ermicioi wrote:
>> If that's the case, then 1036 wins imho, by simple thing of 
>> not doing any parsing of format string.
>
> Consider the overhead 1036 has by comparing it with plain 
> writeln or writefln:

How is this related to original argument of not requiring any 
parsing to be done by user inside function that accepts istring, 
that you replied to?

I personally would be ok with any overhead 1036 adds as long as I 
don't need to do any extra work such as parsing.

Please take into consideration also code inside function that 
does accept interpolated string. I'm pretty sure that parsing of 
format string inside dip1027 function would result in bigger and 
more complex generated code, than overhead you've mentioned for 
1036 version, for use cases similar to logging I've mentioned.