Better use of abbreviated unit identifiers

[JohelEGP]

For a long while now, I've thought that it'd be great if we could naturally write the following.

using namespace units::literals;
using namespace units::constants;
const auto speed_limit = 90_km/h;

However, we need to write 90_km/1_h as the abbreviated unit identifiers happened to be taken up by some "tags."

What do you think about repurposing these identifiers to somewhere else, like the units::constants namespace, where they'd be declared along the lines of:

inline constexpr time::hour_t<int> h(1);

This would allow us to more naturally express units in our programs. The standard time library already allows expressing dates using the natural syntax, like 1970y/January/1. I don't see why we shouldn't follow suit.

[nholthaus]

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 is better than constants though?

[JohelEGP]

I had thought about it, and people using namespace units::literals; for the UDLs might find themselves having undesired clashes or accidentally using these kind of "constant literals". However, I haven't come up with something better.

[nholthaus]

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 as an exercise to the user. If you have a bunch of single letter variables or unit abbreviations as variables, you may need/want a refactor for units anyway.

…

On Fri, Oct 26, 2018 at 3:55 PM Johel Ernesto Guerrero Peña < ***@***.***> wrote: I had thought about it, and people using namespace units::literals; for the UDLs might find themselves having undesired clashes or accidentally using these kind of "constant literals". However, I haven't come up with something better. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#196 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ2HH-m6b4RqNOt623NXDpq4BmQoWEgtks5uo2jPgaJpZM4XaS3N> .

[JohelEGP]

Yeah. literals might be good enough most of the time.

[nholthaus]

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 < ***@***.***> wrote: Yeah. literals might be good enough most of the time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#196 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ2HH3ykHZLD4xu1DDyG1SYag5YbYCR3ks5uo205gaJpZM4XaS3N> .

[JohelEGP]

#256 removes the abbreviation-named tags.

[JohelEGP]

#212 blocks a general solution for this.

[nholthaus]

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, since arithmetic has a different meaning in log space.

[JohelEGP]

Alternatively, dB should be pluralized, like how all other units were renamed (I don't know if there are others). Then dB would be freed up for this.

[nholthaus]

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 for decibel_scale types, and I think even if it did that would still result in watts?

[JohelEGP]

Right. Let's leave non-linear scales off this.

[nholthaus]

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

[JohelEGP]

Well, it should be easy to implement, given that only arithmetic types are supported at the moment.

[JohelEGP]

I have an initial implementation: https://github.com/johelegp/units/tree/natural_syntax. But the restriction of the underlying type being an arithmetic type gets in the way. It'd be easier if there was support for generalized underlying types.

[nholthaus]

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 was obvious and a trait was readily available. I might have thought it was advantageous for trivial units, but I forget the motivation behind that. Probably some constexpr limitation in older compilers.