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

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

Thread Previous | Thread Next
From:
Yuki Kimoto
Date:
March 11, 2022 01:20
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
CAExogxNE9ps7FLcovTFpH1uKXkU8TyTdaU+=zbByMRHDYm-Ngw@mail.gmail.com
I have a question.

What means the scalar value is created as a number for JSON serialization?

  # Created as a number
  my $num = 0;

  # Replace 0 with "0"
  $num =~ s/0/0/;

  # Is this result 0 or "0"?
  my $json_num = to_json $num;


2022-2-24 7:03 Graham Knop <haarg@haarg.org> 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.
>

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