I understand that there may be other requirements that dictate the design. It's just that the specific one that you gave originally - that of displaying the values - strikes me as something that shouldn't be difficult even when you have units reflected statically in the type system.
> At the point where you convert to unitless you lose all the benefit of strong types.
Right, but if you do that right before it actually gets displayed, then it shouldn't be a problem since all actual computations have been performed already? I mean, you also need to convert numbers to text to render them, so all the same arguments apply.
So e.g. in the "ideal" desktop app using MVVM, that would happen on the boundary between the model and the view-model.
> One part of that trade off that you are adding the ability to convert to unitless and thus making it easy to use unitless where you shouldn't.
But any typed unit-of-measure system inherently has such an ability if it tracks units properly for arithmetic operations - you just divide by 1 of the same unit to get a unitless value. E.g. in F#:
let v = 10<m/s> // in m/s
let n = v / 1<m/s> // unitless
> At the point where you convert to unitless you lose all the benefit of strong types.
Right, but if you do that right before it actually gets displayed, then it shouldn't be a problem since all actual computations have been performed already? I mean, you also need to convert numbers to text to render them, so all the same arguments apply.
So e.g. in the "ideal" desktop app using MVVM, that would happen on the boundary between the model and the view-model.
> One part of that trade off that you are adding the ability to convert to unitless and thus making it easy to use unitless where you shouldn't.
But any typed unit-of-measure system inherently has such an ability if it tracks units properly for arithmetic operations - you just divide by 1 of the same unit to get a unitless value. E.g. in F#: