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

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

Thread Previous | Thread Next
Dan Book
February 24, 2022 05:20
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On Thu, Feb 24, 2022 at 12:10 AM Darren Duncan <>

> On 2022-02-23 2:03 p.m., 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.
> 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.

This is not simply a choice for one programmer to make in isolation. If not
done carefully it has effects on all parts of the code that touches those
scalar values, such as CPAN modules and existing code that was written with
a specific interpretation.

> 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.

This isn't the argument being made. It's a bad idea to provide it under
that name because it implies something that is not being enforced. If it
were something different perhaps it would make sense but that would require
even more fundamental language changes.


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