value() and value_type about units

[nholthaus]

In some ways both terms are lacking.

value() implies that a unit consists of two separate parts, a container and a value which is contained. This is sort of the opposite of how I see units; in my mind units are trivial types, not containers. 3_m is the value. Someday I want people to think of raw arithmetic types the same way they do for raw pointers, a.k.a. distasteful and best avoided (all things being equal). When that happens, value starts to make less sense.

magnitude() kind of makes sense (more so in boost/physunits which also have the quantity syntax), but usually magnitude in physics implies no dimension or direction, so does it really make sense if the magnitude() returned a negative value? It does have implications of being a mathematical transform, which I like.

operator() is probably the worst, because of how often it requires a double-parenthesis ()() syntax, and that it gives no context. The only merit is brevity.

unit_cast<...>() to me is the most standard-ese. It's an explicit cast for a potentially unsafe operation, and it's reminiscent of std::chrono::duration_cast<...>(). It makes it clear that you are losing something, and implies to readers (correctly) that something kludegy was happening for some reason. to<..>() is basically just unit_cast in member-function form.

Don't take these musings to mean that I've made a decision.

As far as standardization goes, I'd prefer the committee was making these types of calls instead of myself, but naming conventions are easily changed in the future std fork so I'm not too worry about making the "wrong" decision in v2.3.0.

[nholthaus]

easy enough. I'll think about it tonight and if there are no unintended consequences could roll it into a v2.2.1.

You may not want it to be so easy to carry around .value() though. Unless it's an interface boundary, I suspect unit_t<...> can be used without conversion to arithmetic types in many more places than boost::units.

I'm assuming that you're also already familiar with the fact that the underlying type can be accessed with operator(), as well as the to<..>() function, which will cast the value to any desired arithmetic type.

[martinmoene]

and if at all add it: s/value()/magnitude()/ ?

[nholthaus]

@martinmoene I think unless it matched the boost syntax exactly then there isn't any point? Since you can already get to the underlying value using:

• operator() (member)
• unit_cast<...>() (static)
• to<...>() (member)

[JaapAap]

I have lots of .value() –s in my (boost.units based code), and adding inline constexpr T value() const noexcept { return m_value; } really eases replacing the underlying lib for me. The operator() is the best replacement which has the same implementation, but I honestly dislike it because it gives me lots of places where I get two pairs of brackets (so code becomes SomeClass.getAngle()() ) to get the underlying value (which in my case is mainly needed for unit testing), which is much harder to read than SomeClass.getAngle().value().

…

-Pieter From: Nic Holthaus [mailto:[email protected]] Sent: Friday, February 10, 2017 11:50 PM To: nholthaus/units Cc: Pieter Ober; Author Subject: Re: [nholthaus/units] value() and value_type (#56) @martinmoene <https://github.com/martinmoene> I think unless it matched the boost syntax exactly then there isn't any point? Since you can already get to the underlying value using: * operator() (member) * unit_cast<...>() (static) * to<...>() (member) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#56 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHeq0U4PmaW-cq8MDgTWKhMe1EqazUyjks5rbOmugaJpZM4L95ZJ> . <https://github.com/notifications/beacon/AHeq0YUS_2OGm10OWu9XR8ArwJQlU40jks5rbOmugaJpZM4L95ZJ.gif>

[martinmoene]

Instead of thinking about backwards compatibility, I was thinking forward about standardization. In case one explicitly would want to use a quantity's magnitude, magnitude() might better express that intent than value() does. Just to have it mentioned.

[JaapAap]

I don’t necessarily disagree, but I would think value() somehow feels more standardese. Furthermore, ‘magnitude’ is itself a physical (astronomical) quantity, and to me it somehow feels uneasy to speak of ‘5’ as the ‘magnitude’ of a distance of 5 meters or a mass of 5 kg (I guess because it is a mathematical rather than a physical concept, and related to scale (or direction) more than units). Having said that, both seem hard to misinterpret. Wonder what the native speaker(s) think here! From: Martin Moene [mailto:[email protected]] Sent: Saturday, February 11, 2017 10:38 AM To: nholthaus/units Cc: Pieter Ober; Author Subject: Re: [nholthaus/units] value() and value_type (#56) Instead of thinking about backwards compatibility, I was thinking forward about standardization. In case one explicitly would want to use a quantity's magnitude, magnitude() might better express that intent than value() does. Just to have it mentioned. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#56 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHeq0UWf7NY8U0Xk5ujK706tfUrg19D3ks5rbYF0gaJpZM4L95ZJ> . <https://github.com/notifications/beacon/AHeq0fLYKUeLrGfY5Wq6PDSXLOL0qRpUks5rbYF0gaJpZM4L95ZJ.gif>

[JaapAap]

Interesting musings indeed. In any case, it would imho still be really useful to have a way to get the value in its underlying_type, without having to specify the type to cast too, to avoid getting something like auto x = unit_cast<meter_t::underlying_type>(some_distance_in_m). I would say that value() or magnitude() would rather map to chrono’s count() method, but count is only a good name when the underlying type is an integer I suppose. From: Nic Holthaus [mailto:[email protected]] Sent: Saturday, February 11, 2017 7:41 PM To: nholthaus/units Cc: Pieter Ober; Author Subject: Re: [nholthaus/units] value() and value_type (#56) In some ways both terms are lacking. value() implies that a unit consists of two separate parts, a container and a value which is contained. This is sort of the opposite of how I see units; in my mind units are trivial types, not containers 3_m is the value. Someday I want people to think of raw arithmetic types the same way they do for raw pointers, a.k.a. distasteful and best avoided (all things being equal). When that happens, value starts to make less sense. magnitude() kind of makes sense (more so in boost/physunits which also have the quantity syntax), but usually magnitude in physics implies no dimension or direction, so does it really make sense if the magnitude() returned a negative value? It does have implications of being a mathematical transform, which I like operator() is probably the worst, because of how often is required a double-parenthesis ()() syntax, and that it gives no context. The only merit is brevity. unit_cast<...>() to me is the most standard-ese. It's an explicit cast for a potentially unsafe operation, and it's reminiscent of std::chrono::duration_cast<...>(). It makes it clear that you are losing something, and implies to readers (correctly) that something kludegy was happening for some reason. to<..>() is basically just unit_cast in member-function form. Don't take these musings to mean that I've made a decision. As far as standardization goes, I'd prefer the committee was making these types of calls instead of myself, but naming conventions are easily changed in the future std fork so I'm not too worry about making the "wrong" decision in v2.3.0. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#56 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHeq0XQAn_9zOdDw487LKWI8Id1iC1Orks5rbgDLgaJpZM4L95ZJ> . <https://github.com/notifications/beacon/AHeq0VaSvz36vSHBoTH1Ayj_sDkrliQTks5rbgDLgaJpZM4L95ZJ.gif>

[nholthaus]

I'm going to put this into the next version. I think overall it does no harm. Whether it's carried forward into a standardization proposal is another matter (and my recommendation would be that it isn't for the reasons already given; in fact I'd strip out all accessors aside from unit_cast).