Larry Gritz

I haven't used locale in production code before today, either! Meaning, I always naively assumed tinyformat would print the same for everybody as it did for me, "123.45". And hence...

BTW, I agree that for the string case, there are potentially two use cases: force C locale, or use the native/global one. I really struggled with this issue myself, but...

I'd be for the "all existing versions use C locale, new funcs for explicit", I think that's consistent and probably in line with what 99% of users *think* is really...

I didn't have any thread safety issues that I knew about for sure... just musing about unknowns, but I guess you're right, we're already accepting that tinyformat is changing (and...

So what's the verdict, @c42f ? I think our choices are: 1. Abandon this PR, you don't want to deal with it. PRO: easy for you. CON: leaves the problems....

Both! My use of tinyformat is in two software packages, and in both cases their heart is a library that's used from inside other applications (used by wide range of...

I'm currently of the opinion that the unadorned format() should always use "C" locale. It seems nearly foolproof, your points 2-3 are very compelling. I agree that the main use...

FYI: https://en.wikipedia.org/wiki/Decimal_mark?section=8#Hindu.E2.80.93Arabic_numeral_system

At this time, I have no objection to just having the two common options (C and global), and we can add the other if we want it later.

Dammit, there's no winning on this. What about the string versions? Is there any performance difference? So, potential strategies to mitigate perf issues: 1. Default behavior is always to follow...