[moron4hire]

Yeah, that's pretty much exactly the issue I ran into. The problem is that the standard .NET type semantics can only infer "up" the inheritance hierarchy.

I had gotten really close. I had types like

    Base
    Length: Base
    Meters: Length
    Feet: Length
    
    Compound<Base, Base>
    Area<T>: Compound<T, T> where T: Length
    SquareMeters: Area<Meters>
    SquareFeet: Area<Feet>

and had defined all of my math as generic extension methods of the Base class so that the types would compose:

    Compound<T, U> Multiply<T, U>(T a, U b) where T : Base where U : Base
    T Divide<T, U>(Compound<T, U>, U b) where T : Base where U : Base
    

That went a long way towards getting fairly concrete types out of only a few lines of code. But I couldn't get it the rest of the way. C# explicitly forbids user-defined typecasts between types in an inheritance chain with each other, so while multiplying two Meters got me a Compound<Meters, Meters>, it was not then possible to take a Compound<Meter, Meter> and convert it to anything like Area<Meters> or SquareMeters automatically.

[platz]

Interesting problem! I was wondering why even define things like SquareMeters, but as you say the issues is reducing the terms that have different forms but mean the same thing.

[moron4hire]

Having a SquareMeters type was meant to reduce complexity. Instead of always dealing with Area<Meters, Meters> all the time, it was meant to be a shortcut.

Hrm, what about namespace aliasing? "using SquareMeters = Composite<Meters, Meters>"? Since the problem is not the composition of the type but the verbosity of the deeply composited types, then perhaps it's just about making a shortcut for the name.

[platz]

things can be composed different ways. m/s^2 should equal (m/s)/s

[moron4hire]

Okay, I've definitely convinced myself there is no good way to do this without having to write way too much code over and over again. The problem is basically equivalent to inserting items into a sorted list, but you only have one operation in which to do it. So, you are either limited to simple types, or your code for operations on types explodes trying to define all of the ways to compare types (in a generic sense) and different scenarios for combinations of types.

This requires a Turing-complete type system.