Hi Yuval,
I'm not sure about that. You had two ideas, the first was to forward everything to the value_type, so you'll have a us_dollar value_type, etc. I thing it's not convenient. Most users will find something like
quantity<currency/*, default to double*/> q1(1500.0 * us_dollar);
makes more sense than
quantity<currency, us_dollar> q1(1500.0);
It certainly fits the rest of the library better, IMO. More than that,
Maybe - for me, it makes more sense to modify the value_type in this way, but this was just an off-the-cuff example of how one could accomplish time- varying currency conversions with compile-time dimension checking in the simplest (from the ease of implementation standpoint) way. I'm not sure I agree that using a double precision value_type fits the rest of the library better, though - I have spent a significant amount of time and effort to get the library to gracefully and correctly handle any value_type that models the necessary concepts, so it should be value_type agnostic as much as possible.
the second idea of extending the SI system pretty much, AFAIU, forces the value_type to *not* be anything like us_dollar - it should fit length and mass to!
This was presented as an option for convenience; you certainly don't have to extend the SI system. But you may be right; if we're mixing physical units and currency units, you may need to implement specific currency systems and the conversions between them...
So I believe it boils down to providing a runtime-changeable conversion ratios for some units (currency), in addition to the currently fixed ratios for other units (physics). Whether or not you want to support it, is a completely different matter...
You can do this already; it requires more work, because the conversion_helper class (in conversion.hpp) needs to be specialized to work with currency systems to accommodate the time-varying conversion factor. That all being said, I personally don't feel that dealing with currencies (among a number of other specialized use cases that have been proposed along the way during the discussions of this domain) is a reasonable expectation for this library to support out of the box; I have tried to make it flexible enough to deal with a wide range of potential applications, but for those applications that lie outside standard dimensional/analysis and units, I expect that users will use this library as a foundation for their specific application. Matthias