Nic Holthaus

This is part of the reason I don't love first-class integral units. I think this is a deficiency in gcc/clang. With MSVC the following operation: ``` cpp meters c(16); c...

you're specifically referring to this? ``` cpp template constexpr UnitTypeLhs& operator*=(UnitTypeLhs& lhs, const typename UnitTypeLhs::underlying_type& rhs) noexcept ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ { lhs = lhs * rhs; return lhs; } ``` In that...

Yes, this. It never crossed my mind honestly but I _love_ the natural syntax. That's the ethos and purpose of the library in the first place. Maybe the literals namespace...

hmm, good point. I still like inlining the real constants namespace, we can call these `literal_constants` or something like that. That said, I may be OK leaving the clash resolution...

if not we'll just patch it out in v3.1 I suppose... On Fri, Oct 26, 2018 at 4:14 PM Johel Ernesto Guerrero Peña < [email protected]> wrote: > Yeah. literals might...

all the concentration unit names were expanded, so only dB uses an abbreviation. I'm pretty sure we don't want to use operators like `/` and `*` to change linear scales,...

I don't have a problem with pluralizing the names, but I don't think it will work as intended. I can't do `20 * dB * W` because `operator*` isn't defined...

I think we're good to go then, I really want this as part of the release.

totally agree. I think the criticisms against being able to use `std::complex` are particularly valid. I don't think there was any additional rationale for `arithmetic` underlying types than that it...

in addition we should split the different unit types into constituent header files. I've resisted this in the past because have a single-header library is kind of nice, but the...