Re: [RFC] [Discussion] Literal Scalar Types

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