develooper Front page | perl.perl5.porters | Postings from March 2022

Re: Pre-RFC: builtin:: functions for detecting numbers vs strings

Thread Previous | Thread Next
Karl Williamson
March 8, 2022 16:25
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On 3/8/22 07:38, Graham Knop wrote:
> On Fri, Mar 4, 2022 at 4:29 PM Paul "LeoNerd" Evans
> <> wrote:
>> After further discussion with PSC, we'd like to keep moving this
>> forward. There's still time to add new functions to builtin:: in time
>> for 5.36, and it would be nice to get these in.
>> We agree that they should not be named "isnumber" and "isstring",
>> mostly because of your concerns about leading people to think they do
>> something that they don't.
>> I'd like to suggest you write up an RFC on this request, perhaps
>> beginning with the names
>>    builtin::was_originally_number
>>    builtin::was_originally_string
>> They're sufficiently long and unwieldy as to mildly discourage people
>> from using them except when absolutely necessary (read: on JSON
>> serialisers and similar), and the name itself doesn't suggest it tells
>> you current information about the actual type of a value, merely tells
>> you the history on how it started.
> I've created an RFC PR:
> In the RFC, I'm using the names builtin::created_as_number and
> builtin::created_as_string. Justification is included in the RFC, but
> I think these better match what we want their return values to
> represent. And I personally, was_originally_number feels really
> awkward as a function name. The names could still be changed of
> course; I'm not overly attached to what I've chosen.

I think "created_as..." are better than previous suggestions

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About