Open JohelEGP opened 5 years ago
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?
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.
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 < notifications@github.com> 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 https://github.com/nholthaus/units/issues/196#issuecomment-433525374, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ2HH-m6b4RqNOt623NXDpq4BmQoWEgtks5uo2jPgaJpZM4XaS3N .
Yeah. literals
might be good enough most of the time.
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 < notifications@github.com> 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 https://github.com/nholthaus/units/issues/196#issuecomment-433530192, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ2HH3ykHZLD4xu1DDyG1SYag5YbYCR3ks5uo205gaJpZM4XaS3N .
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.
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.
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
?
Right. Let's leave non-linear scales off this.
I think we're good to go then, I really want this as part of the release.
Well, it should be easy to implement, given that only arithmetic types are supported at the moment.
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.
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.
For a long while now, I've thought that it'd be great if we could naturally write the following.
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: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.