On Thursday, 10 September 2015 at 07:01:19 UTC, David Nadlinger
wrote:
You must be confusing the library with something else (or me
with another David). I'm pretty sure that my original
proof-of-concept is the most flexible of all of them, coming
with support for composing arbitrary runtime conversion
functions, affine quantities and so on. SI unit definitions are
merely predefined in a second module because they are commonly
used.
That being said, my implementation is ages old and could
probably be done much better today.
- David
I've gained time and energy to take up this task again. It seems
like David Nadlinger's solution is very complete:
https://github.com/klickverbot/phobos/tree/undefined
http://klickverbot.at/code/units/std_units.html
http://klickverbot.at/code/units/std_units.html#PrefixSystem
but not a complete superset of
https://github.com/nordlow/quantities/tree/master/source/undefined
One key issue here is whether we should provide an instantiator
based API
auto q = 1.0.meter;
or operator plus constants/CT-constants (via David's std.si)
import std.si : meter;
const q = 1.0*meter;
or a combined (my proposal)
auto q = 1.0.meters; // plural naming
auto q = 1.0*meter; // singular naming
for expressing quantities.
David's SI-unit solution is, IMO, better than biozic's as it
doesn't force the unit to be associated with a specific numerical
scalar type upon construction.
Another key-question is whether we should support biozic's
compile-time parsing of unit expressions such as
- 1.0.si!"km/h"
- 1.0.si!"m/s"
etc.
Could somebody point out if something is missing in David's
solution. And, if so, which parts of biozic's which could be
reused.
that could/should be reused for filling in these gaps.
Another key-issue is if the template `Rational` in std.units
should be extracted and put into a separate module.
I vote for moving forward with David's solution.
