Any RFC for Units of Measure?

[JoeyAcc]

Total ordering in general is not, and won’t be, feasible in Rust without major rearchitecting the core language. In other words: don’t hold your breath

A simple but crucial counterexample is what happens when you use e.g. f64 values as components of a more complex type e.g. A * B. Floats cannot be totally ordered due to the existence of the various Inf and NaN semi-values.

[DrSensor]

Love to have Units of Measurement in Rust. Seems it can be achieved by creating compiler plugins for it

[JeanMertz]

I would also be happy to see better support in Rust for units of measurement. Since edition 2018 is around the corner, and features such as trait specialisation are more fleshed out now, anyone have any update on which direction we should go with this, and if there have been any promising experiments in the last ~3 months?

[scottmcm]

anyone have any update on which direction we should go with this?

I think the biggest unknown is how far a library solution will be able to get with const generics, so anything moving that forward would probably help. (There might well be language changes needed too, but hopefully few, and it’s currently unknown which.)

[varkor]

There might well be language changes needed too, but hopefully few, and it’s currently unknown which.

As far as I can tell, the only functionality it’s not possible to construct in a library (after const generics is complete) is canonicalisation of dimension types (e.g. such that m / s^2 is the same as s / (s^3 / m)). To support this in the language, you either need to make units of measure first-class, with the canonicalisation logic inside the language itself, or provide type-level functions (just type -> type, not necessarily full HKTs). (I wrote a little about this.)

[newpavlov]

I don’t think that we should allow 3.0[mm] + 5.0[ft], even though both values represent length. Rust generally avoids implicit conversions, so I don’t think it’s a good idea to introduce such large source of implicitness via units system. We may even go further and distinguish between unit and how it’s stored in memory, so the same Meter unit will be usable with f32, f64, u32, etc. and 1u32[m] + 0.1f32[m] will produce an error, though I am not sure if it’s worth the associated complexity.

[varkor]

I don’t think that we should allow 3.0[mm] + 5.0[ft] , even though both values represent length.

Yeah, this is a pragmatic decision that could (and probably would) be sensible to make if UoM did make it into Rust. The exact representation is an important question too: I think parameterising by the type of the quantity (e.g. u32, f32, etc.) would also probably be useful.

These are essentially library questions, however, so it’s probably worth waiting until we have a proposed solution for the language problem (canonicalisation) before bikeshedding about those questions.

[gbutler]

I don’t think that we should allow 3.0[mm] + 5.0[ft] ,

That seems to me to be an odd and counter-productive position. Especially considering that: 5.6[km] + 2.3[nm] is likely to result in a much more off-the-wall and useless value than 5.0[m] + 3.0[ft].

[gnzlbg]

s far as I can tell, the only functionality it’s not possible to construct in a library (after const generics is complete) is canonicalisation of dimension types

I think that whether this is possible or not depends on which particular approach we settle on.

We could, for example, have a single type constructor per system of units where all base units are encoded in the Unit type as type-level consts: SI::Unit</*time*/-1, /*length*/ 1, ...>, such that each operation on units like Mul or Add generates new already canonicalized types by operating on the exponents.

Converting between systems is then just an impl From<GCS::Unit> for SI::Unit away. This has pros and cons, but is doable in a library.

[newpavlov]

I should’ve mentioned that 5.6[km] + 2.3[nm] probably should be disallowed as well without an explicit conversion to meters. In other words we will have two different units “kilometers” and “nanometers”, i.e. 5.2f32[nm] will store in memory 5.32, not 5.32e-9. But of course I would like to have custom literal “nm” using which I’ll get value in “meter” units. Units and custom literals are related to each other, but probably should not be mixed.

[gbutler]

I should’ve mentioned that 5.6[km] + 2.3[nm] probably should be disallowed as well without an explicit conversion to meters

OK, I see how that would be a more consistent position, I’m just not sure I understand why you would find that useful. Why should I be able to do 5.0[m] + 0.00000000032[m] but not be able to do 5.0[m] + 3.2[nm] or 10000[in] + 3.2[Gm].

[newpavlov]

Again, you mix custom literals and units of measurment. I was talking about units, not about literals. If nm and m in 5.0[m] + 3.2[nm] are custom literals which desugar to Meters(5.0) + Meter(3.2e-9), I have no problem with it. But if it desugars to Meter(5.0) + Nanometer(3.2) I think we should heavily discourage allowing such operations.

[gbutler]

I guess I’d like to see units of measure be in terms of hierarchies/dimensions. For example, the “length” dimension has several units of measure hierarchies, the 2 obvious ones are:

• etc -> Gm -> Mm -> km -> m -> cm -> mm -> etc
• etc -> Miles -> Yards -> Feet -> Inches -> etc

A dimension of length consists of a number of components from a particular hierarchy of the length dimension. When adding values from the same hierarchies, the components are added directly, when adding values from different hierarchies, the secondary hierarchy’s components are converted to closes order of magnitude component of the primary hierarchy before then adding the components. Something like that would give the greatest flexibility and accuracy to my mind.

[gbutler]

I think we should heavily discourage allowing such operations.

I still don’t understand why you think that. I understand it is your position, I just don’t think I understand why it is your position.

[newpavlov]

I just don’t think I understand why it is your position.

I believe my position is in line with the current Rust approach to implicit conversions between types (and units are essentially subset of types), i.e. it’s currently forbidden to write code like this 1u32 + 1.3f32 even though some may say that conversion here is “trivial” and should be done automatically.

[gbutler]

Yes, but, forbidding adding different units of measure simply because they express different magnitudes is more akin to forbidding:

let x : f32 = 0.0000000001;
let y : f32 = 1413411351;
let z = x + y; // forbidden because the magnitudes are so different that there will be potential loss of information

Which we don’t forbid in reality, rather than:

let x : f32 = 0.0000000001;
let y : i32 = 1413411351;
let z = x + y; // forbidden because there will be loss of precision that you may not be thinking about because f32 and i32 have different ranges and precisions available to them. 

Which we do in fact forbid in reality. I guess I just don’t see those as the same thing at all. Perhaps it’s just me though.

[madmalik]

I still don’t understand why you think that. I understand it is your position, I just don’t think I understand why it is your position.

I can’t answer for @newpavlov, but i’m of the same opinion. 1m is very different from 1000mm are very different in terms of precision and range. 1 usize mm would convert to 0 usize meters, a very big usize meter measure might overflow when converting to mm.

I’ve a background in industrial automation and units of measure is something i really missed there (i’m doing other stuff now). But at least in that context most conversions between dimensions require decisions about what to preserve - range or precision.

Of course, all of this is moot if a meter is just sugar for literal 1000 mm (or any other arbitrary base length). But that has its own challenges. I’d argue that it would be surprising if a f32 would be unable to encode the length of 1 meter precisely because the base length is one nanometer.

I’d also argue that (at least in engineering contexts) a wild mix of different dimensions is a sign of badly designed system and shouldn’t be encouraged, but thats just an opinion and offtopic.

[varkor]

We could, for example, have a single type constructor per system of units where all base units are encoded in the Unit type as type-level consts: SI::Unit</*time*/-1, /*length*/ 1, ...> , such that each operation on units like Mul or Add generates new already canonicalized types by operating on the exponents.

If I’m not misunderstanding something, this approach would make every expansion of the set of base dimensions (for any “unit” type) a breaking change, without a language feature like variadic generics, which seems like a show-stopper.

[gnzlbg]

If I’m not misunderstanding something, this approach would make every expansion of the set of base dimensions (for any “unit” type) a breaking change,

I think this would depend on how exactly we would allow the system unit types (e.g. SI::Unit) to leak, if at all. If we only expose concrete unit types like SI::meter and SI::second that hide the Unit type (e.g. via new types), then we could add new base dimensions as an implementation detail of the SI unit system. An alternative might be to use default const parameters (analogous to default type parameters on nightly) for new base units.

[gnzlbg]

Also, adding new base dimensions to the main unit systems does not happen often. Anecdotally, in ~15 years of boost units, I recall it happening once for SI. In such a Rust library, we would just bump the major version and let people upgrade whenever they can (we could add a compatibility layer with the previous version).