Should we rename `quantity::number()` to `value()`?

[mpusz]

ISO/IEC Guide 99:2007 says:

quantity property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference

On the other hand, it also specifies a term numerical quantity value

numerical quantity value numerical value of a quantity numerical value number in the expression of a quantity value, other than any number serving as the reference

ISO 80000-1:2022 in chapter 6.2 says:

...any other quantity of the same kind can be expressed in terms of this unit, as a product of this unit and a number. That number is called the numerical value of the quantity expressed in this unit. It is essential to distinguish between the quantity itself and the numerical value of the quantity expressed in a particular unit.

[JohelEGP]

I bet SG15 has good input on this. Anyways, going by the name alone, what value returns is less clear than number. I'd just document that number returns the numerical quantity value.

[m5k8]

+1 for value().

[BenFrantzDale]

I'm cool with value. Per https://github.com/mpusz/units/issues/434 and https://github.com/mpusz/units/issues/412 I think it needs to be fully explicit when you pack and unpack values in order to be robust against refactorings (and to just be fully clear: f(foo.value()) doesn't mean anything; f(foo.value_in<millimeters>()) does.

[mpusz]

Sure, if we decide to rename it, we will change the name of both functions.

[JohelEGP]

The data for containers only returns part of the value, as you need size to be able to traverse the data. Except for std::string, which is null-terminated. That's why I'm against #423. A quantity value is already a value, so quantity::value returning the number/numerical quantity value feels wrong. -- Extract from https://github.com/mpusz/mp-units/issues/477#issuecomment-1660840414.

[nuuSolutions]

Not sure why this is even a question. For me (as a physicist) a quantity is specified by a value, a unit and possibly some additional reference system.

number() just sounds completely off and always makes me wonder if it is an integer. Sure, a value is represented by a (real or natural) number, but that's one level below. In other words: mathematics/CS has numbers, physics has values!

I would also be fine with numerical_value() and numerical_value_in<mm>() although this seems a bit verbose. Then again these should not be used too much in code.

[mpusz]

Is seems we should revise this issue. Today I was going again through the terms in ISO and SI to check for a better alternative of Reference (issue #486) and I found the following:

quantity value, value of a quantity value

number and reference together expressing magni­tude of a quantity

EXAMPLE 1:Length of a given rod: 5.34 m or 534 cm

https://jcgm.bipm.org/vim/en/1.19.html

It seems that according to both ISO and SI, the "value" contains both a number and a unit, but in this feature, we return only a number. So maybe we should revert the previous number() and number_in() member functions?

[mpusz]

Alternatively, as proposed by @JohelEGP above we could use numerical_value as the official documentation states:

numerical quantity value, numerical value of a quantity, numerical value

number in the expression of a quantity value, other than any number serving as the reference

https://jcgm.bipm.org/vim/en/1.20.html