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.

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.

I feel like 'int' ought to have a stronger contract of doing what's written on the label.

The documentation for int() says that it "Returns the integer portion of EXPR".
It's using "integer" in the mathematical sense of "whole number", not in the programming sense of "IV".
It just so happens that with the most commonly used builds of perl (where IV precision >= NV precision) every EXPR that (in numeric context) contains a fractional portion will also truncate to a value that fits into an IV ... so I can see how the confusion might arise.
But, for example, we don't want int(2 ** 65) to start returning '0' or 'undef' or IV_MAX just because it's too big to fit into an IV.

If you switch to a perl where IV precision < NV precision (such as perls whose IV size is 4 bytes, or whose NV type is __float128), then you'll encounter lots of cases where EXPR contains values with a fractional portion, and yet has an integer portion that's too big to fit into an IV.
On those builds, and for those values of EXPR, int(EXPR) will happily and silently return just the "whole number" portion of EXPR as an NV.

Cheers,
Rob

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

int doesn't contract to return an IV; it contracts to return the integer portion of the expression given. An infinitely large floating point would convert to an infinitely large integer, so infinity is still the logical conclusion (IMO).

In my mind, perl's int is equivalent to c's math.h:'trunc', not the int typecast in c.

#include <math.h>
#include <stdio.h>
int main()
{
    double x;
    x = 3.14;      printf("trunc(%f) = %f\n", x, trunc(x));
    x = -2.718;    printf("trunc(%f) = %f\n", x, trunc(x));
    x = +INFINITY; printf("trunc(%f) = %f\n", x, trunc(x));
    x = -INFINITY; printf("trunc(%f) = %f\n", x, trunc(x));
    x = +NAN;      printf("trunc(%f) = %f\n", x, trunc(x));
    x = -NAN;      printf("trunc(%f) = %f\n", x, trunc(x));
}
[download]

output:

trunc(3.140000) = 3.000000
trunc(-2.718000) = -2.000000
trunc(inf) = inf
trunc(-inf) = -inf
trunc(nan) = nan
trunc(nan) = nan
[download]

The docs for int could be improved to say what it does on those edge cases (the trunc docs that I linked do explicitly define those behaviors), but I personally think that int returns the right thing for those inputs, and for me, it is the Answer 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.

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.