Replacement for snprintf

[Jonathan M Davis]

On Thursday, 31 October 2019 09:58:08 MDT H. S. Teoh via Digitalmars-d 
wrote:
> On Thu, Oct 31, 2019 at 10:14:59AM +0000, Guillaume Piolat via 
Digitalmars-d wrote:
> > On Thursday, 31 October 2019 at 01:09:14 UTC, Walter Bright wrote:
> > > Replacing snprintf for floating point is very challenging, because:
> > >
> > > 1. people have been improving snprintf for decades
> > > 2. people expect precision and performance
> > > 3. the standard is snprintf, any credible implementation must be the
> > > same or better
> >
> > Moreover, actual printf implementations seems to depend upon the
> > locale.  This creates bugs (say "1,4" instead of "1.4") so this
> > behaviour depends if you want to be bug-compatible. We've been hit by
> > that in `printed` when used with a Russian locale.
>
> *Is* it a bug, though?  Arguably, the reason snprintf was done that way
> was precisely to support properly-formatted output in the current
> locale. I.e., when outputting Russian text, the convention is to write
> the decimal point with "," rather than ".". It would be considered wrong
> or strange to write "1.4" instead of "1,4". This is important if you
> want to support i18n in your program.
>
> But if you're outputting to, say, JSON, then you *don't* ever want
> "1,4", you only want "1.4".
>
> Which leads me to think that these two should be separate format
> specifiers. Unfortunately, I can see how this would force format() to be
> impure, because to support checking the current locale implies accessing
> global state, which is impure.

The version of format that takes the format specifier as a compile-time
argument shouldn't have that problem, but the one that took it as a runtime
argument certainly would.

- Jonathan M Davis