F# has "Units of Measure" that does this. https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

Why do you want these compilation errors?

Both are measures of length. I can add an inch and a centimeter, and the result is a well defined length that we can express in inches, centimeters, light years, or any other measure of length. Likewise for areas or ratios of lengths.

I would generally prefer it if the language just gave me the correct result, which I can then print out in the user's preferred unit.

Adding inches and raw centimetres is like adding apples and oranges, which they taught us not to do in grade school.

What you are thinking of is:

in1 = cm1.toInches();

If someone passes cm to a function that expects inches, much error and grief will result.

No, I'm not thinking of

   dec1 = hex1.toDecimal();

because

   num1 = 0xff00 + 64;

works just as well and so does

   functionThatExpectsNumber(0b1101);

as does

   p1 = mat1 * vec1;

Lengths are just as absolute as integers, but we have different ways to input and represent them. A sufficiently advanced language understands the equivalences and does just the right thing. Adding apples and oranges does not happen.

Generally your function should not expect inches, it should expect some length and I can input it in any unit of length I want.

Sure there are cases where you're constrained and need to account for the limited range and precision of your underlying storage format, but that should not be the default for any modern high level general purpose programming language. We don't need to concern ourselves with grade school stuff, the computer can do it for us.

Adding apples to oranges is concern at a lower level than the abstraction we should be working with by default. Doing arithmetic by hand on pen and paper is pretty low level.

Adding apples to oranges is also a concern when you don't have proper types by which the system can deduce that orange is actually just 2.54*apple.

You're missing the point. I make an app that prints charts. It includes a function that subtracts user-specified margins from the paper width, to calculate available space. Some of my customers are in the U.S (inches), others are not (cm).

If I call

    printPage(0.75, 0.75);

you really think it's going to be all the same whether "0.75" represents inches or centimetres?

I am not sure if your "I want a language where I can" is followed by an implicit ", and C++ is that language" or ", I wish it existed".

I am guessing the former as your example is possible with C++ but it doesn't seem like a great example as you are using units of measure for your types. There are languages that support those and obviously, in such a case, assigning centimeters or inches to a distance-typed variable is both ok. The type error would be in mixing distance and, say, weight.

I meant C++. I'm using this currently in C++ production code. Has saved me tons of debugging.

What I meant was that if I'm going to look at a new language, I would expect it to support this type of functionality.

I suppose I can enhance the classes and overload the operators to automatically convert from cm to inches when doing mixed arithmetic. But this will quickly become insanely complicated when considering all possible permutations of arithmetic operators.

It would be great to have dimensional analysis in typing systems of programming languages.

F# has had typed units of measure for over a decade, with Hindley-Milner style type-inference, so you can do stuff like

   let foo x y = (x:int<m>) * y + 10<m/s>;;

And it infers that y has type <1/s>.

You can add whatever dimensional types you want.

I believe you can do this with distinct type aliases in Nim:

https://nim-by-example.github.io/types/distinct/