Allow "infinity" and ignore case when parsing floats.

[clarfonthey]

This fixes #48881.

[pietroalbini]

Thanks for this PR! Unfortunately, highfive failed to assign a reviewer to this PR. Picking someone randomly from the libs team. @dtolnay?

[dtolnay]

The code looks good but what do you see as the use cases of this? What are some examples where an application would not have been able to use f64::from_str before but would want to after this change?

[petrochenkov]

ping @rkruppe

[clarfonthey]

@dtolnay there are a few examples in the original issue; I think that once inf, INF, NaN, NAN, and nan are allowed, it just makes more sense to simplify the code and allow any case. The usage of "infinity" was just an extra I thought of though, and can be removed if it seems unnecessary.

[dtolnay]

I just feel that "can unambiguously be interpreted as an f64" is not the set of inputs that f64::from_str would ideally accept. We define what the function accepts, and if someone wants to call the function they are expected to pass input the way we defined it. For that purpose I see the current set of "inf" and "NaN" as being sufficient. If someone is writing a YAML library for example and YAML's infinity is spelled ".inf", there should be no expectation that f64::from_str is the tool they need to use.

[clarfonthey]

That is understandable! If you think that this wouldn't be worth having I can close this PR.

[dtolnay]

I appreciate the PR but let's keep this the way it is. Thanks!

[JohnBSmith]

It seems understandable to me too, I have found more than one reason that speaks against it. First of all, this would have been a subtle breaking change, as the return value's specification including its error cases belongs to the interface. Then, making a small and clear interface more complex is controversial and should not be taken lightly. And if the exact syntax definition differs, a validating parser needs to handle the cases that don't match [sign] ('.' | digit) by itself anyway.