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 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/>
Attachment:
signature.asc
Description: PGP signature