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
