RFC: Units of measurement for D (Phobos?)

[David Nadlinger via Digitalmars-d]

On Tuesday, 15 March 2016 at 09:07:05 UTC, Nordlöw wrote:
> On Monday, 14 March 2016 at 18:51:45 UTC, Chris Wright wrote:
>> Ohm my, that's awesome. Watt needs to happen to get this into 
>> Phobos?
>
> I'm cleaning up David's work right and will put up a PR today.

Please make a really, really thorough pass through the source 
before proposing it for Phobos.

The code was written in a dark age where CTFE bugs were very 
common (e.g. trying to use std.algorithm.sort would give weird 
results), there was a number of issues with template parameters, 
and many relevant features simply did not exist yet:
  - UFCS (!)
  - UDAs
  - Extracting template symbol/arguments from template instances
  - Natural alias syntax ("=")
  - alias/enum/… templates
  - Eponymous templates with extra members
  - …

Back then, getting this to work with a half-reasonable API in 
spite of all the compiler bugs and limitations was quite the tour 
de force (IIRC some of the issues are marked using @@BUG@@ in the 
code, but that was by far not all of them). With the current 
compilers, it should be much more a question of design than of 
implementation.

The basic design should still be sound, though. The main 
decisions to make concern not so much the implementation (or 
whether unit string parsing is implemented, etc.) but the level 
of flexibility in the unit and conversion structure. One such 
decision would be whether to store
   a) the numerical value verbatim in the units specified by the 
user, or
   b) in some distinguished base unit for the given dimension.
Another such question is whether to use
   1) a pre-defined, closed system of dimensions (e.g. the SI 
units),
   2) an explicit, but extensible structure of dimensions (to 
which units can be assigned), or
   3) units can arbitrarily be created and the concept of 
dimensions emerges implicitly from conversions between them.

The less flexible solutions often have the advantage of allowing 
a simpler implementation, being easier to understand for the 
novice user (less types/templates) and possibly being quicker to 
compile.

For my original library, the general motif was the to follow the 
most expressive and flexible solution (3) and a) in the above). 
For instance, on top of the obvious consequences regarding 
precision, going with a) allows you to seamlessly interface with 
non-unit-aware code and to define runtime conversions that are 
only applied when actually requested by the user. Similar 
considerations apply to other aspects of the design.

  — David