RFC: Units of measurement for D (Phobos?)

Nordlöw via Digitalmars-d digitalmars-d at puremagic.com
Mon Mar 14 02:04:28 PDT 2016


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.


More information about the Digitalmars-d mailing list