Printing floating points

[Berni44]

On Wednesday, 27 January 2021 at 01:16:40 UTC, Bruce Carneal 
wrote:
> I'd vote for "overweight and almost-certainly-correct" over 
> "trim but iffy" if the extra poundage is reasonable which, in 
> the non-embedded environments, it appears to be.

I'd like to compare the task to write floating point numbers to 
building a car: You need a chassis, wheels, seats and other 
stuff. And you need an engine. The engine in the PR is a simple 
division by 10 (as explained above). Ryu Printf would be an other 
engine, a better one when concerned of speed only (but much worse 
in memory usage). But all else of the car would remain the same 
(and is not touched by the proof of Ryu Printf, as far as I 
know). (My plan is to start with a simple engine and replace that 
one by better ones step by step.)

Coming back to your vote, I'd say it's a vote between "overweight 
and almost-certainly-correct" vs. "trim and correct". I don't say 
that, because I'm overly self confident, but because the "engine" 
I used is quite simple. And furthermore, that simple engine is 
already part of phobos (in the %e-car) sind almost one year, I 
just reuse it for the %f-car.

> A large body of others believe that ryu is a good way to go and 
> are moving to standardize on it.
>
> It's not a live-or-die issue for me but ryu looks pretty good.

We are in complete agreement here. My point is: Adding ryu printf 
would be the second step before the first step: First build the 
car with a simple engine (that's what the PR does) and then 
replace this engine by a better one. I will (probably) do this 
job, but only in this order.

Adding ryu is jet another unrelated step. I've got plans to add 
ryu, or at least to prepare everything for adding it. But to do 
this std.format needs some other improvements (including 
refactoring) first, in order to add some space, where ryu nicely 
fits in. PR #7765 (splitting std.format into submodules) is the 
first step here, not absolutely needed, but with all these 
additions IMHO std.format is getting too large. It also 
simplifies working in parallel on replacing snprintf and 
improving the rest of std.format.