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:34
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On Thu, Feb 24, 2022 at 12:30 AM Darren Duncan <>

> On 2022-02-23 9:19 p.m., Dan Book wrote:
> > On Thu, Feb 24, 2022 at 12:10 AM Darren Duncan wrote:
> >     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.
> As I understand it, all these added functions do is return information on
> their
> argument, and they don't modify or have side effects on their argument in
> any
> way.  And so any one using those functions won't affect the behavior of
> any code
> but their own and code which uses their own, which is the same as how
> things
> work generally anyway.
> >     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.
> I can completely get behind the idea of properly naming the functions so
> that
> their names correspond to their actual meanings.  Mainly what I care about
> is
> that the functions exist at all, whatever they are called.
> On a related note, the original proposed names were for parity with
> isbool().
> So if the new ones are going to have names like was_input_as_number(),
> then
> isbool() should similarly be renamed to was_input_as_boolean() or such.
> Consistency is important.

They don't need to be consistent since they do different things. isbool
returns true for only two scalar values which can only ever be booleans.
Numbers and strings in general however can become also numbers or strings
during their lifetime, regardless how they started.


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