Would a PR to add optional support for C++20 concepts be considered, or is that out of scope for this library?
I've experimented with adding concepts based on the is_<dimension>_unit_v traits, and it seemed to work fairly well. The only issue I ran into was name clashes if the standard library concept naming convention were used (e.g., clashes with namespace names or between dimensionless the concept and dimensionless the unit), and that's fairly easily solved by sticking concepts into their own namespace or by using PascalCase.
And a somewhat related question - should is_dimensionless_unit_v and/or a dimensionless concept be true or false for built-in artithmetic types?
Would a PR to add optional support for C++20 concepts be considered, or is that out of scope for this library?
I've experimented with adding concepts based on the
is_<dimension>_unit_vtraits, and it seemed to work fairly well. The only issue I ran into was name clashes if the standard library concept naming convention were used (e.g., clashes with namespace names or betweendimensionlessthe concept anddimensionlessthe unit), and that's fairly easily solved by sticking concepts into their own namespace or by using PascalCase.And a somewhat related question - should
is_dimensionless_unit_vand/or adimensionlessconcept be true or false for built-in artithmetic types?