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

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

Thread Previous | Thread Next
From:
Darren Duncan
Date:
February 24, 2022 05:09
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
2ace8a09-0464-cbda-9cd1-3fff84155af4@darrenduncan.net
On 2022-02-23 2:03 p.m., Graham Knop wrote:
> After the merge of https://github.com/Perl/perl5/pull/18958, 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.

We definitely SHOULD have these functions.  I think I even argued for them a few 
months ago during the boolean thread.

As far as I'm concerned, strong and strict typing is a GOOD thing in general, 
not just for serializers but more generally.

I feel that your stated concern about the availability of these functions 
encouraging use to be misplaced.  There is absolutely nothing wrong about people 
using these functions for validation or anything else.

In fact we should go further, having the same kinds of functions to distinguish 
integers and floats.

Also for distinguishing character strings from octet strings.

Maybe string "2" and number 2 are supposed to be interchangeable in Perl, but 
users should have the choice as to whether they want them to be interchangeable.

For backwards compatibility all the built-in existing functions and operators 
that treated them as interchangeable before should continue to do so.

The whole idea of denying users functions like builtin::isnumber etc because 
they might want to actually use them for things they are well suited for, that 
very much goes against Perl's core idea that there's more than one way to do it, 
and is unnecessarily forcing one's personal preferences on others.

I agree that there are some things that are more legitimately bad coding 
practices which shouldn't be made too easy, but strict typing isn't one of them.

-- Darren Duncan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About