> Here's another one: formatting of floating point types. > > That's a hard pass on the Standard Library implementations. We already carry > code for this in the form of libdoubleconversion, so unless we can ditch that > in favour of the Standard Library content, we shouldn't use both, which would > increase QtCore code size and possibly introduce differences in behaviour.
Fair point. We definitely do not want current tr() and new trFormat() produce different results. But then, I'm questioning the need for trFormat(), at least for now. If we implement the entire (or most of) formatting and parsing on our own, then we'll need to support two custom solutions instead of one. And the new one would anyway diverge from what the standard provides. > And we really can't use the the Standard Library ones until sometime in the > 2030s, can we? Yeah, not until we unconditionally switch to C++20. So, maybe we should postpone the new solution until that time, and then create something which is standard-compatible? ------------------------------ Ivan ________________________________________ From: Development <development-boun...@qt-project.org> on behalf of Thiago Macieira <thiago.macie...@intel.com> Sent: Thursday, October 24, 2024 7:58 PM To: development@qt-project.org Subject: Re: [Development] format-like tr() On Thursday 24 October 2024 10:12:35 Pacific Daylight Time Thiago Macieira wrote: > > IMO, we could benefit from the new syntax, if we could build our > > implementation on top of what the standard provides for us. But I see > > little benefit in reimplementing the standard from scratch. > > I'm hoping we don't have to do it all. But I don't know yet how far we can > go. Especially since we mean to do a mixed encoding solution: Here's another one: formatting of floating point types. That's a hard pass on the Standard Library implementations. We already carry code for this in the form of libdoubleconversion, so unless we can ditch that in favour of the Standard Library content, we shouldn't use both, which would increase QtCore code size and possibly introduce differences in behaviour. And we really can't use the the Standard Library ones until sometime in the 2030s, can we? -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development