Feature #22085
open`String#to_f` and `Kernel#Float` shouldn't issue out of range warnings
Description
Ruby issue warnings when parsing out of range floats, e.g.:
$ ruby -We '1e184467440737095516160.to_s'
-e:1: warning: Float 1e184467440737095516... out of range
This makes a lot of sense for float literals parsed by the Ruby parser.
However I'm not convinced it makes sense when parsing user input or third party data:
>> '1e184467440737095516160'.to_f
(irb):1: warning: Float 1e184467440737095516... out of range
=> Infinity
>> Float('1e184467440737095516160')
<internal:kernel>:196: warning: Float 1e184467440737095516... out of range
=> Infinity
As these warnings aren't really actionable in most cases.
So I think String#to_f and Kernel#Float shouldn't issue out of range warnings.
Updated by matz (Yukihiro Matsumoto) 16 days ago
I agree the warning is not actionable when the input comes from external data, so dropping it for String#to_f and Kernel#Float is reasonable.
One thing about the scope. The examples here are all overflow to Infinity, but the warning is emitted on ERANGE in general, so it also covers underflow to zero. For example "1e-9999".to_f returns 0.0 with the same warning.
I'm fine with removing the warning for the overflow case. Infinity announces itself. It propagates through arithmetic and is easy to notice in the result.
Underflow is different. The input is a non-zero number but the result is 0.0, which is silent and can quietly break later computation. I'd like to keep the warning for the underflow-to-zero case.
So my preference is to limit this change to the overflow (Infinity) case, and keep the warning for underflow. What do you think?
Matz.
Updated by byroot (Jean Boussier) 16 days ago
keep the warning for underflow. What do you think?
I understand where you are coming from, but my opinion is the same for both warnings, they're not actionable.
Granted, these are verbose warnings, so mostly intended for development and test, but if I want to test that my program handles underflow input correctly, I now need to suppress warnings for that test case.
Which is what brought me to open this issue, as I was trying to test JSON.parse handling of overflow/underflow:
NUMBERS.each do |number|
assert_equal Float(number), JSON.parse(number)
end
My opinion is that when user input in concerns, it's best to either raise loudly, or say nothing, similar to "not-a-number".to_i or Integer("not-a-umber").