
( 1.0 * SI::meters + 1.0 * imperial::feet ) * ( 2.0 * CGS::centimeters + 1.0 * imperial::feet )
I'm not proposing to allow heterogeneous addition where, as you point out, the result type is ambiguous. Multiplication/division don't have this problem, though. Your example would give 2.0 m cm + 1.0 m ft + 2.0 ft cm + 1.0 ft^2 which wouldn't be allowed due to the addition of different units. Any quantity h as a dimensional signature that consists (limiting the discussion to physical units for simplicity) of the powers of the various dimensions. That is (calling length L, time T, and mass M) L^2 M^-3 T is a dimensional signature that could be represented all in SI: m^2 kg^-3 s or mixed SI and CGS m cm kg^-1 g^-2 s m cm kg^-2 g s etc... As long as you can come up with an invertible one-to-one map between different heterogeneous units with identical dimensional signatures, this is OK.
and other complex expressions. Pushing down a result type may be hard. If your result type is nautical::miles * imperial::miles, how do you decide which of the two branches needs to get the nautical::miles? And this is a relatively simple example.
Another issue, as Steven pointed out, is that it is harder to get a nice syntax in the case where you want a function that takes a dimension signature but doesn't care about the system (or systems) of units. That is, the current implementation, which requires that all fundamental units belong to one system, lets you do this: template<class System> quantity<unit<System,energy_type> > work(const quantity<unit<System,force_type> >& F, const quantity<unit<System,length_type> >& dx) { return F*dx; } or even template<class System1,class System2,class System3> quantity<unit<System3,energy_type> > work(const quantity<unit<System1,force_type> >& F, const quantity<unit<System2,length_type> >& dx) { const quantity<unit<System3,force_type> > Fc(F); const quantity<unit<System3,length_type> > dxc(dx); return Fc*dxc; } when you allow units to be heterogeneous across systems, it becomes difficult to implement this...suggestions are welcome... Maybe this is too much of a hairball to try to deal with. Matthias