[Edit] it also handled things like parallel resistances, etc.
It was in C++ if I recall correctly.
This is a great idea, that I've haven't had cause to use yet.
[1] https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
It's slightly better than languages with no operator overloading nor newtypes at all (well, actually a lot better given other things you can use newtypes for) but without operator overloading using it just for units, with no other API machinery, is usually a bad idea.
1. Don't type units like that.
2. Allow the * operator to multiply a time-unitful value with an untimed scalar and disallow using it with two time-unitful values.
Presumably the requirement that * operands are the same is arbitrarily modifiable and go developers have control over what types operators take.
2. A "time unit" is not a special type of value. You can construct arbitrary types of integers, and it is common to do so. `*` has no clue what a time is, just that it's "not an int" (for example).
(This is especially relevant because you really mean `5 * (2500 * time.Millisecond)` vs. int(5) * (2500 * time.Millisecond)`, as there is no `time.Milliseconds` function.)
> "A NASA review board found that the problem was in the software controlling the orbiter's thrusters. The software calculated the force the thrusters needed to exert in pounds of force. A separate piece of software took in the data assuming it was in the metric unit: newtons.... Propulsion engineers, like those at Lockheed Martin who built the craft, typically express force in pounds, but it was standard practice to convert to newtons for space missions. One pound of force is about 4.45 newtons. Engineers at NASA's Jet Propulsion Lab assumed the conversion had been made, and didn't check."
https://www.wired.com/2010/11/1110mars-climate-observer-repo...
There could be issues with memory use, but it could also be implemented as an API, i.e. ensuring values exported from one software package to another were of the correct type, but then store them internally as simple types... Switching everything to a unified metric system would make more sense in the long run, however.
You could even double-down on it: "Have there been any studies that prove that using units of measure helps you get the right answer?"
(Edit, that's not possible in c++)
Mind expanding on that? Because what that readme there shows is absolutely possible in C++, I have used a similar system for dealing with natural units.
This is a fundamental limitation of types - they tend to scale poorly to very complex non-uniform structures. That's not to say that they shouldn't be used when they do scale nicely, though!
Is this really a common occurrence? In most situations I've come across, it's the matrix itself (rows/columns) that has a unit of measurement, not the invididual columns. Tensors, rotation matrices, lighting maps: they all use the same units of measurement.
And while it may be relatively common to start out and end up with matrices that have a single unit for each row (but different units on different rows), intermediate results will often end up with different combinations of units in each element.