Stream: ideas

Topic: Decoding Float Exponents


view this post on Zulip Luke Boswell (Apr 23 2023 at 03:25):

Should we support E and +, e.g. 12e+2,12E+2 in Str.toF64 as these are currently not supported but commonly used across various programming languages and number formats (XML, Python etc)?

view this post on Zulip Richard Feldman (Apr 23 2023 at 19:17):

I think so yeah :thumbs_up:

view this post on Zulip Richard Feldman (Apr 23 2023 at 19:18):

I'm not sure what exactly the format should be - should look into the pros/cons of various approaches to avoid making the same mistakes other languages have if they ended up going with a design they regret :sweat_smile:

view this post on Zulip Brendan Hansknecht (Apr 23 2023 at 19:45):

Is this just for fractional or also integer types? Would we want this to apply to u128?

view this post on Zulip Sky Rose (May 08 2023 at 17:12):

There is also a GitHub issue about this but it doesn't have much detail yet. https://github.com/roc-lang/roc/issues/5213

view this post on Zulip Andy Ferris (May 02 2024 at 13:43):

This would be very welcome. I would think that literals for NaN, Infinity and -Infinity would be worthwhile (are these already available as constants inside Num or Frac or something?).

As for mistakes other languages have made, I haven't seen huge regrets other than the fact that some syntaxes are redundant (why support both 12e2 and 12E2? The modern form seems to be settled as the lower case e) and some implementations historically didn't produce round-trippable numbers.

Another thing is whether or not there are distinct syntax literals for f64 vs f32 representations.

view this post on Zulip Andy Ferris (May 02 2024 at 13:45):

Brendan Hansknecht said:

Is this just for fractional or also integer types? Would we want this to apply to u128?

In other languages this is only usually defined for fractional types - floats and decimals, but not integers.


Last updated: Jun 16 2026 at 16:19 UTC