Yes, that’s an example. I don’t have the generated module committed, which is probably making what’s happening unclear. See here for the generated module: http://trettel.us/units.f90
As I understand it, there are two ways to implement unit checking with derived types in Fortran. One uses a single derived type and the unit checking is done at run-time (for example: PhysUnits). I would assume that has a heavy run-time cost. The approach I’m taking (also used by quaff) has many derived types and the unit checking is done at compile-time. All the type-bound operators do in the second case is reimplement the operations. The operators in the second case have no explicit code for checking the units. It wasn’t obvious to me that this approach would necessarily have a significant run-time cost.
As I’ve said, I don’t fully understand what compilers are doing under the hood. But it seems to me that it’s possible (though perhaps not easy) in the compile-time unit checking case for the compiler’s optimizer to essentially remove the layer provided by the derived types and get near normal performance. That’s obviously not happening at present.
Edit: I realized after posting this that what I wrote is probably unclear for some, so I’m going to explain how compile-time unit checking works here.
If the derived types don’t check the units in the operators at run-time, then how are the units checked? Basically, only valid operations are implemented. So addition and subtraction are implemented between two identical units, but not between two different units. For multiplication and division, the unit for the result is determined in the generator given particular combinations of left and right arguments. genunits will create all of the appropriate operations, and none of the inappropriate operations. Consequently, if a unit error is made, the compiler won’t know what to do, and a compile-time error will result. This is what I mean by “compile-time unit checking”.