Unfortunately that just isn't the way perl defines things. Perl has no distinction between float/int - not even when int() function is used. Perl scalars essentially have 3 basic flavours: number/string/reference.

Inf and NaN are valid numbers in perl, and int() returns a number. Hence why they don't see anything wrong with int() returning Inf/Nan.

The perl doc for int() not even mentioning inf/nan is another example of how un-user friendly perl is, and IMO is one of the reasons why perl is dieing out.

> one of the reasons why perl is dieing out

I think a bigger problem for Perl is people knowing what can be improved, but instead of submitting a patch, they complain on the internets.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Hence why they don't see anything wrong with int() returning Inf/Nan.

Are you thinking that int($x) should always return an IV ?
It will only ever return an IV if $x, having had its fractional part removed, then fits into an IV.

The int() function does not alter the values of Infs or Nans, and the values of int(NaN) and int(Inf) are not within that IV range - as too, is the case with (eg) int($x) for all $x >  2 ** 64.
In all of those cases, int() returns an NV.

Cheers,
Rob

Yeah that's sort of what I'm going for. I feel like 'int' ought to have a stronger contract of doing what's written on the label. If it can't convert to an int, it ought to return undef or 0, not just ignore the attempt, under the Principle of Least Astonishment.

Unfortunately that just isn't the way perl defines things. Perl has no distinction between float/int - not even when int() function is used. Perl scalars essentially have 3 basic flavours: number/string/reference. Inf and NaN are valid numbers in perl, and int() returns a number. Hence why they don't see anything wrong with int() returning Inf/Nan.

That's not correct. Perl internals *do* distinguish between signed/unsigned ints, floats, and strings. Aside from internals, there *isn't* a distinction between numbers and strings, but every perl operator gets to decide how it will coerce its input, and the operators do generally fall into categories of "number operators" and "string operators", but nothing forces that convention.

Against that backdrop, and the existence of the "use integer" pragma, I would expect a function named "int" to always cast its argument to an integer, or maybe 'undef' for failures.

perl -E 'my $x= "NaN"; say $x+0; say int($x); { use integer; say $x+0 
+}'
NaN
NaN
0
[download]

I sincerely doubt this has anything to do with perl's decline. JavaScript and PHP have ten times as many shoddy API edge cases.