Being able to assign a unit of measure to a numeric type is really helpful for ensuring correctness. Stopping a programmer from accidentally adding a value in metres to one in either inches or in seconds is at least as important as stopping them from adding an int to a float.
F# is the only language I know that has this built in. I always thought it was a good feature. You can roll it yourself in languages with support for compile-time type calculations.; in my job I write unit safe C++ through the company's own library.
I don't think it would be possible to create this in user-space in Roc, even if overloading of arithmetic operators were allowed. There is no way to work out what the return type should be for a generic multiplication or division of quantities with units. On the other hand, that sort of calculation is something zig seems to shine at and so I think it might be worth the effort to build it into the language.
There was a previous, related discussion, but that was for requiring units on a numeric type, which I don't think is a good idea.
I see this has been officially proposed.
I think it would be good to have a motion of base units and (thus) conversions between values with the same dimensions in different units. I've mostly seen this done with a compile-time, constant, fractional value in each derived-unit type referring back to the "product of base units" type for the same dimension.
Also, in my experience, you pretty often want to take a square root of quantities with dimensions that are square powers of each base dimension and rarely want to use this operation when it would produce fractional powers. So having a square root function defined only for "square" units is a reasonable option (and cube root for cubic units etc). Otherwise, a fractional type for the power could fix the problem of double underflow in the type system discussed in the proposal.
Last updated: Jun 16 2026 at 16:19 UTC