Johel Ernesto Guerrero Peña

> I can see an additional duration-like interface being valuable, but a key design principle (maybe the only one) of this lib is allowing implicit conversions when it's safe to...

What's the difference of that to `units::unit`? `units::unit` is good enough. It just needs the mixed-type support that `std::common_type` would give it in the return type, and a implementation of...

I wouldn't mind making v3 work with C++14.

> [Code cleanliness and a lot of criticism from WG21 that it's not "modern" enough to act as a reference implementation for a future `std` library. I probably can't use...

Please, remind me what did you mean by "named" conversion factors.

So you mean removing the strong conversion factors and leave only `conversion_factor`?

> The readability gain in the definitions is more than offset by the readability loss to the user. The former can be retained. And I like it.

By using the unit's `conversion_factor` member alias.

Basically #256 without the bits that remove the strong conversion factors, thanks to this line: ```C++ abbreviation, ::units::decibel_scale, typename ::units::namespaceName::namePlural::conversion_factor) /** @} */ \ ``` There are a few redundant...

> so sometimes when you leave an issue open for two years, you don't really know what was going on and discover it wasn't a good idea. This is one...