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:
Darren Duncan
Date:
March 12, 2022 03:10
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
3d36344d-6a40-77a7-c7b2-a58cca75006b@darrenduncan.net
On 2022-03-11 1:19 p.m., William Lindley wrote:
> In all this discussion, what happens when reading a file containing the line:
> 
> 01730
> 
> which is the postal code for my hometown.  This "looks like" a number but if 
> treated like one, the leading zero is liable be dropped, leaving invalid postcode
> 
> 1730
> 
> In more-pathological cases, 01730 could be interpreted as an octal number (984 
> decimal).
> 
> It is disheartening that Perl's "be forgiving in what you accept; be strict at 
> what you output" is violated by so many newer protocols.

What do you mean by "a file"?

Context is everything.

Of course we would expect different behaviors depending on the type of the file, 
where the postal code is in the file, whether or not it is quoted, and so on.

In the general case of a generic file read using generic file operations, your 
line would be read as a character string, and all the characters would be preserved.

You would only lose the leading zero if you were reading the file with something 
that was treating it as JSON or some other special format, or if you fed the 
line to a mathematical operation like adding zero to it.

I don't see a problem here.

What is an example scenario where you think Perl would do the wrong thing with 
your postal code?

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