Unexpected output from units::concentration::percent_t::to<...>() about units

[MikeGitb]

100 % equals 1, so this is what I would expect.

[GElliott]

I agree that the output should be 1.0, but shouldn't the constructor instead take 1.0? My point is that the scales between constructor parameter and output value seem to be mismatched.

[nholthaus]

that's as designed. 1.0/1.0 == 100%. If you gave 1.0 to the constructor, that would mean 1.0%, e.g. 0.01.

[chiphogg]

It does seem as though this is an inconsistency in the library. Consider the following test case:

TEST(toDouble, consistency) {
    EXPECT_EQ(::units::length::millimeter_t{50}.to<double>(), 50);       // OK
    EXPECT_EQ(::units::length::mile_t{50}.to<double>(), 50);             // OK
    EXPECT_EQ(::units::concentration::percent_t{50}.to<double>(), 0.5);  // surprise!
}

Typically in this library, for scaled units, .to<double>() is expected to produce the value in the natively stored unit. percent_t does not work like that.

I think the operation that's supposed to give 1.0 here would be implicit conversion to double. I believe it already does the right thing here, so the thing to do (in principle!) would be to change the explicit .to<double>() to be consistent with everything else.

Unfortunately, if this argument is valid, there are probably tremendously many users in the wild which rely on this behaviour, so it's hard for me to see how to fix it.