Hi On 6/15/26 21:45, Seifeddine Gmati wrote:
For what it is worth, I am personally fine with `tenths(0.1 + 0.2)` failing to match `0.3`. This is not new behaviour: `0.1 + 0.2 == 0.3` is already false, and a `match (0.1 + 0.2)` already skips a `0.3` arm for exactly the same reason. So a literal float type behaves consistently with comparison and `match`, rather than introducing a new surprise.
Yes, it is consistent with the existing behavior, but I don't think that this makes it any less confusing. And for this specific proposal, adding support for floats would be a deliberate decision rather than just something that naturally follows from “existing === semantics” as with `match()` which works on two values rather than values + types.
On your concrete questions: `4e3` is a valid float literal and works today; it normalizes to `4000.0` (the type also stringifies as `4000.0`). `NAN` and `INF`, on the other hand, are not literals but constant identifiers that go through constant resolution. They are out of scope for the same reason `FOO` is above: `NAN $foo` could just as well mean a class named `NAN`.
Yes, I'm aware (based on a look at the implementation). This was intended to be a subtle note that this is not explicitly spelled out in the RFC.
The RFC text should comprehensively explain the behavior all possible edge cases and ambiguities so that folks can form an educated opinion based on the RFC text alone without needing to be able to understand the implementation.
Writing that out, I also notice that the “Ecosystem” sub-section is missing from the “RFC Impact” section (and the “To Existing Extensions ” sub-subsection would probably also be useful to know) and the voting widget is also missing.
Best regards Tim Düsterhus
