RFC: SI Units facility for Phobos

[Andrei Alexandrescu]

Benjamin Shropshire wrote an SI Units implementation which he refers to 
here:

http://d.puremagic.com/issues/show_bug.cgi?id=3725

For convenience, here are direct links to the code:

http://www.dsource.org/projects/scrapple/browser/trunk/units/si2.d
http://www.dsource.org/projects/scrapple/browser/trunk/units/rational.d

This cannot be considered a reviewable proposal yet because it doesn't 
have sufficient documentation and is essentially in the stage where 
Benjamin is asking for input on improving the design and implementation.

Below are my comments in response to Benjamin's RFC. In brief, the 
design is a bit off from what I hope to have an a units library, but 
things can be fixed without too much difficulty by shuffling things around.

* Call the library std.units and generally focus on units, not on SI units.

* I suggest doing away with abstract unit names ("Distance", "Time", 
"Mass" etc.) and use concrete plural units ("Meters", "Seconds", 
"Kilograms" etc) instead. I agree that at a level operating with the 
abstract names seems to be more pure, but at a concrete level you need 
to have various reference points. For example, a molecular physics 
program would want to operate with Angstroms, which should be a distinct 
type from Meters.

* There should be ways to define scalars of distinct types and 
relationships between them. For example, "Radians" and "Degrees" should 
be distinct types, although both are scalar.

* The previous points bring me to an important design artifact: each and 
every unit should have a multiplier (constant, template argument) that 
describes its relationship to the SI corresponding entity. The SI units 
themselves will have a 1.0 multiplier, and e.g. Angstroms has a 1e10 
multiplier. The current library has a facility for that, but I think 
that's not as good.

* In the proposed design the user can define a lot of distinct types, 
such as Miles, Yards, and Lbs, which are strictly unnecessary 
(Kilometers, Meters, and Kilograms could be used instead, with 
appropriate I/O conversions to and from other units). I think offering 
scale-less units chosen by the user is a good thing as long as there is 
a unified mechanism for converting between those units without risking 
confusion and bugs.

* There should be no implicit conversion to double and generally few 
conversion smarts. The units should have a writable public field "value".

* There should also be a property called siValue which yields the value, 
converted to SI, of type double. For an Angstroms, siValue returns value 
* 1e-10.

(Step-by-step on the code:)

* The code should use TypeTyple instead of T.

* I think FullSI should be always in effect. Even though many users 
don't care for lumens and moles, they can just sit there defaulted at 
the very end and shouldn't be bothersome.

* Each artifact (extra, extra2, Batch...) should be documented.

* I'm not sure about the use of fractional exponents. They add a fair 
amount of complication. Could we dump them or use a simple fixed-point 
scheme to accommodate them?

* The naming convention should consistently use NamesLikeThis for types 
and namesLikeThis for values (including constants).

* A scheme similar to std.conv.to should serve as an all-around 
converter, e.g. to!Kilometers(Miles(10)) should yield a value of type 
Kilometers that contains 16.05 or whatever.

* All operators should be converted to D2 (yet another success story of 
the new design :o)).

* Packages of remarkable constants would be nice to have, of course in 
the appropriate units. The fields of astronomy, classical/relativistic 
mechanics, electromagnetism, molecular physics, quantum mechanics, come 
to mind.

All - please add your comments. Benjamin, I hope you're as enthusiastic 
as always about pushing this into Phobos!


Andrei