On Fri, Feb 25, 2022 at 11:40 AM Paul "LeoNerd" Evans < leonerd@leonerd.org.uk> wrote: > On Fri, 25 Feb 2022 17:21:58 +0100 > demerphq <demerphq@gmail.com> wrote: > > > On Thu, 24 Feb 2022 at 17:31, Paul "LeoNerd" Evans > > <leonerd@leonerd.org.uk> wrote: > > > > > At this point I suddenly don't even like the word "Type". But > > > currently I don't have a better one - words like "nature", "facet", > > > "ability" or "capability" all feel wrong somehow. > > > > > > > This reminds me of looks_like_a_number() which pops up all over the > > place. And I wonder if we even need to have a test for "looks like > > text", if we have tests for everything else then the only thing left > > is "text" (without getting into debates about whether the text is > > pure-octets, or unicode or whatever). > > Yes; indeed when briefly discussing these "was originally > number/string" functions on the PSC call today, Rik mentioned > looks_like_a_number. It's quite similar on intent and naming scheme. > > I also note that we don't (yet) have a builtin::looks_like_a_number so > perhaps there'd be scope for adding all three of these together, where > the documentation can point out to would-be users of > "was_originally_number" that they almost-certainly didn't want that > function and should instead consider "looks_like_a_number". > It's important to keep in mind that looks_like_number is really "could be used in a numeric operation without numeric warnings" (naming is hard as always). It accepts far more things than most people expect it would by the name alone, so is often insufficient for type constraints - e.g. '0e0' and 'inf' are accepted. But this probably does mean it fits the same problem space as "was originally number". -DanThread Previous | Thread Next