Feature #22085: `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings

• Status: Closed
• Assignee: -
• Target version: -

[byroot (Jean Boussier)]

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.

[matz (Yukihiro Matsumoto)]

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.

[byroot (Jean Boussier)]

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").

[byroot (Jean Boussier)]

Another case of this warning needing to be worked around: https://github.com/ruby/json/pull/1044

[matz (Yukihiro Matsumoto)]

Accepted.

The out of range warning is meant for float literals in source code, where the programmer can fix the literal. For runtime conversion of user input or external data, the warning is not actionable, and the return value (Infinity) is already well defined. String#to_f and Kernel#Float should just return the value silently.

Matz.

[byroot (Jean Boussier)]

• Status changed from Open to Closed

Applied in changeset git|b416f906cf29a3586d3378e147db24f7c39cae3f.

---

Remove String#to_f and Kernel#Float out of range warning

[Feature #22085]

This warning is only actionable for float literals in source code.
When parsing user input into a float, most of the time this warning
isn't actionable and is pure noise.