humidity default is inconsistent between impl_from_str and from_base_units

[hkBst]

The impl_from_str macro should probably use <$t>::from_base_units instead of $d (see end of src/measurements.rs).

Unfortunately this causes humidity tests to fail, because for humidity from_ratio is the impl of from_base_units, but $d is from_percentage. This inconsistency (factor 100 difference) causes tests to fail. Changing this would probably be a silent API change..., but I don't know.

[thejpster]

Pinging @trappitsch on this one.

[trappitsch]

Well, for humidity, the impl_from_str is new and as of yet unpublished. However, there are other failures if you would do that impl, especially temperature (which had a FromStr impl from before).
Here, the base unit is Kelvin, but strings without a unit were always parsed as Celsius. The guess here is (I assume as this was the impl from before I did #74) that if you don't supply a unit you mean Celsius... which is probably not true for people living in the US and for physicists ;)

For humidity: If you pick ratio as the base unit, you have the same "problem" as for Fraction (see here), namely that the base unit has no symbol. In general, humidity and fraction are the same as they technically have no units, however, they describe two very different concepts. Humidity and Fraction are the only two modules where I think a unitless (number only) string makes perfect sense, as you always know in this case that it must be the ratio, while you pick the "most likely" option in other cases, which will be subjective.

For these reasons (and to keep with the previous API as close as possible), the impl_from_str macro is open to choose the standard unit when implementing "FromStr".

[hkBst]

Maybe from_str should just not accept strings which don't include a unit for quantities that aren't just numbers?

[trappitsch]

I would agree here, but that's for sure an API breaking change. If it is decided that this should be done, I would propose to also toss out that, empty strings error as well, they currently return 0.0 and the default unit.