RFC FS-1148 - Ease conversion between Units of Measure (UoM) and undecorated numerals and simplify casting

[roboz0r]

Click “Files changed” → “⋯” → “View file” for the rendered RFC.

• Add new Units type to ease UoM conversions dotnet/fsharp#17518

[vzarytovskii]

This is my personal concern - it's a lot of new surface area and probably a bunch of sigdata, optdata and il.

[roboz0r]

Incremental size is around 31KB which translates to roughly 163 bytes per method. I don't really have a have a sense of whether that is acceptable or not. If the majority of F# users aren't making extensive use of UoM then there's no sense in making them carry around any extra weight.

The part of the feature that I sense would answer the most questions for users is removal of units from primitives. If I can call LanguagePrimitives.FloatWithMeasure, I'd expect the inverse LanguagePrimitives.FloatWithoutMeasure, although the same effect is currently available with the existing primitive conversion methods like float.

Maybe the collections are better off in a FSharp.Collections.Units or as an addition to FSharp.UMX that has an essentially identical API using overloaded methods for primitives extended to non-numeric types?

[vzarytovskii]

In general, currently, I believe that in this form (method per type per action, etc) it should live in a separate library (be part of UMX)? However, I generally think that this particular functionality (add, strip measure) can and should be solved generically (i.e. we should have one type directed generic function stripMeasure<_> and one addMeasure<_> which will do the magic), though it might require some work in compiler.

[roboz0r]

Based on Don's comments

(2) and (3) [generic UoM conversion] require 'T<'m> as a construct, or a new kind of constraint, or a special type-checking rule. Thus they look complex.

I took "complex" to mean something I wouldn't be capable of as a novice contributor. Do you have a sense of how complex and pervasive such an addition would be?