On Tue, Mar 18, 2025 at 10:35:53PM +0100, Alejandro Colomar wrote: > Hi Joseph, > > On Tue, Mar 18, 2025 at 09:11:58PM +0000, Joseph Myers wrote: > > > > > 7.24.2 Numeric conversion functions > > > > > New section _before_ 7.24.2.2 (The atof function). > > > > > > > > You're missing corresponding <wchar.h> functions. > > > > > > As with other proposals, I prefer leaving it for a different paper. > > > I'm not an expert in wchar stuff. > > > > I strongly disapprove of this approach to making standard proposals; if > > everyone does this, it's a recipe for turning the standard into an > > inconsistent, non-orthogonal mess, where each feature only has sensible > > interactions with the subset of other features the proposer of the new > > feature was interested in at the time they added it. > > > > As far as I'm concerned, it's the responsibility of the person making a > > proposal to produce a complete proposal with properly orthogonal > > interaction with other features. I objected to the unsuccessful attempt > > to define complex literals that didn't allow for Annex H types, and I > > object likewise to randomly proposing functions, for a family that has > > corresponding <wchar.h> functions, without the corresponding <wchar.h> > > versions. If a proposal is to add some non-orthogonal feature, there > > needs to be a good and clearly stated reason why, *as part of the overall > > language and library design*, it makes sense that way. That is, not > > something relating to your interest or expertise in <wchar.h> functions, > > but something about the technical content of the standard that makes > > having some strto* functions with corresponding wcsto* functions and these > > ones without corresponding wcsto* functions into a logically coherent > > design. > > Okay, let's try with some more rationale: > > NetBSD has strtoi/u(3), but not wcstoi/u(3), AFAICS. This is prior art. > > I don't feel qualified to propose a function for a family (wchar.h) > which I have never used myself, nor implemented. > > I think it would make sense to present two papers at the same time, one > proposing the wchar.h variant, and one presenting the normal variant. I > just don't feel qualified to decide whether we want a wchar_t variant, > nor to specify it myself. > > On the other hand, I feel qualified to propose strtoi/u(3), and think it > is quite necessary in the standard, regardless of what happens to the > wchar_t variant. > > If someone who is an expert in wide strings wants to work with me on the > specification of a wide variant, I'm happy to help. But I can't do that > myself alone. > > > (I don't care about Annex K myself - but I still made sure that my recent > > report of issue 1012 included the relevant Annex K edits.) > > > > > > I'm also concerned that the names sound like int / unsigned int analogues > > > > of strtol, but aren't. > > > > > > I don't get to choose the name. Anyway, my plans are to erradicate > > > > You do get to choose the name when making a new proposal. If an existing > > name is defective through suggesting an incorrect analogy, that would be a > > reasonable basis to choose a new one. > > Yeah, I could choose it, if I had a better one. I did that for the > case of Plan9's seprint(2), which I called aprintf(). However, in this s/seprint/smprint/ > case, I don't have an idea for a significantly better name, and > considering that the number of arguments makes accidents impossible, > there aren't strong reasons to deviate from prior art. > > > Have a lovely night! > Alex > > -- > <https://www.alejandro-colomar.es/> -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature