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

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

Thread Previous | Thread Next
Darren Duncan
March 14, 2022 05:37
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
I made good name proposals already:

- is_canonically_a_number()
- is_canonically_a_string()
- is_canonically_a_boolean()

-- Darren Duncan

On 2022-03-13 8:46 p.m., Yuki Kimoto wrote:
> My understanding:
> Perl 5.36+ can detect a string and a number completely.
>    a string - SvPOK
>    a number - (SvIOK or SvNOK) and not SvPOK
> However, we don't want to say these are "is_number" and "is_string" because Perl 
> used to manipulate a number and a string as the same thing for a long time.
> We search for good names except for "is_number" and "is_string".
> 2022-2-24 7:03 Graham Knop < <>> wrote:
>     After the merge of
>     <>, it is
>     possible to reliably distinguish between values that started as
>     numbers vs values that started as strings. Essentially, if the POK
>     flag is set, the value started as a string. If the POK flag is not set
>     and IOK or NOK is set, it started as a number. These flags can be
>     checked in XS, or via the B module, but cannot currently be checked in
>     pure perl. For serializers, being able to detect the original type of
>     a value is essential, so it would help to provide functions to provide
>     this information. For example, providing builtin::isnumber and
>     builtin::isstring, to go along with builtin::isbool.
>     This does potentially have a huge impact on the language as a whole.
>     While this is needed for serializers, providing easy access to this
>     type data will pretty much inevitably result in people using the
>     functions within perl for things like parameter validation. The values
>     "2" and 2 are meant to be fully interchangeable inside perl, and new
>     code distinguishing them will break many expectations.
>     Even with caveats, I do think this is something that the language
>     should provide. I am uncertain on the naming of the functions.
>     builtin::isnumber and builtin::isstring are perhaps the most
>     obvious, but they also imply that distinguishing these types is a
>     normal thing to do. We may want the function names to be more
>     opinionated, implying more strongly that they are meant to be used for
>     things like serialization, not internal type checking. That feels like
>     a losing battle though once any function of this type is available.

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