Replacement for snprintf

[H. S. Teoh]

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.


T

-- 
I'm still trying to find a pun for "punishment"...