I'll get the ball rolling on the question of whether building a compile time only library is a good choice. My current thinking is yes, it is. I have three basic reasons for this, so I'll list them all below. If the library is going to include a runtime component, it would be for unit conversions on the fly. Various implementation details for this have been discussed in the past, but they always boil down to choosing some annointed set of units that the program will really use, and converting anything that is not in those units to the preferred system (usually during I/O). If answers for users are desired in something other than the preferred system, this conversion is done after the calculations are finished. The goal of this approach is to provide automatic unit conversion, and thereby simplify code, while minimizing the impact on program performance. In some settings I think this is a very usable answer to the problem. However, for my work in specific I do not think it is a good choice. My first problem is with code simplification. In theoretic physics (which is my background), unit systems are chosen based on the problem at hand. The goal is always to simplify the notation and to make reasoning about the problem more natural. If this is done successfully, expressing the resulting equations in code is cleaner and more obvious. For example, the units chosen for many electro-dynamic calculations lead to equations that have no constant multipliers. Lack of these multipliers means no magic numbers hiding in the code, so no way to get confused by said magic numbers. In the part of the code that is the actual calculation, this leads to simplicity and easier debugging, as well as eliminating a few multiplications or divisions. My second problem is with numerical accuracy and stability. The distribution of floating point representable numbers inside the set of the reals is not uniform. Nor is the relative error due to round off uniformly distributed. In most cases, the relative error is minimized close to 1.0. (See references such as Accuracy and Stability of Numerical Algorithms by Nicholas Higham for details.) Thus, it is almost always advisable to use units where the quantities in the code are in the range around 1.0 in numerical calculations. There is no silver bullet for numerical stability any more than there is for any other coding issue, but this is sually good advice. In some cases, a wise choice of units can even make a problem cease to use floating point arithmetic and become a purely integer arithmetic problem (An example would be monte carlo simulation of spontaneous magnetization using the Ising model. More generally, it happens in situations where the discrete nature of quantum states is important.). Obviously, since integer arithmetic is exact, this eliminates all concerns with round off issues. The third problem I see is one of efficiency. In a well chosen unit system there are very few multiplicative constants in the equations that describe the evolution and state of the system. (Systems that manage to have few or no constants and where the measurements of interest are of order 1.0 are sometimes called natural units for the problem.) In the primary calculation of a tight loop, every multiplication or division I can avoid is important. If all calculations actually happen in some pre-determined, but not natural for my problem set of units these multiplications and divisions cannot be avoided, and in some cases become the dominant part of the calculation's use of resources. For simulation work where doubling the operation count on the main loop can be the difference between a project that can be done and one that can't, this is unacceptable. This is my opinion, and the reasons for it. In my work I would not be able to use a system that imposes conversions. Nor would I suggest such a system to my students. I think a system with conversions might be built on top of the library Matthias and Steven have provided (though I'm not sure, since I haven't tried), but one with conversions would be very hard to use as a platform for those of us who need to not have conversions. Thus I think the chosen design is a good one. John