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

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

Thread Previous | Thread Next
Paul "LeoNerd" Evans
March 4, 2022 15:29
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On Wed, 23 Feb 2022 23:03:14 +0100
Graham Knop <> wrote:

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

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


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.

We'll leave as an as-yet unanswered question on how these functions
behave in the presence of a true dualvar, such as

  $x = $!;

  $x = Scalar::Util::dualvar(123, "fourfivesix");

Simultaneously to you hopefully writing that RFC, I'll make a start
actually implementing it. The bulk of the work will be in writing the
implementation, tests, and documentation, which can happen during any
ongoing debate on what the final names should be. Those should be quite
trivially simple to fix up afterwards once it's resolved.

Paul "LeoNerd" Evans      |  |

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