Rename concepts to lower case

[kwikius]

Rename concepts to lower case using in_ prefix. Fixes https://githubcom/mpusz/units/issues/93

Discussed in the abstract rules such as 'no prefix' seem to make sense but step back and look again.
In context when reading source you actually need to be able to identify a concept fast and simply and a consistent prefix does that, especially if you get the right prefix.

so Assume a concept param x X

x can be seen as a set containing models of x and so adding the in_' prefix --> in_x` gives the reader the right meaning X is in the set x , so this prefix also aids the underrated process of source code review. It literally aids reading the source
Anyway you can view how it works in the source code where it actually matters.

( Also fixes #114 Scalar is renamed to in_numeric_value.
I felt that in_value was a little short. in_numeric_value is amorphous enough to be more than just maths. )

[mpusz]

I must say that I am not a fan of an in_ prefix. During the discussions on the ISO C++ committee meetings, I suggested leaving any_ prefix for concepts. However, the quorum was to use it for polymorphic wrappers 😞 in_ is really misleading and clashes with the convention of prefixing in and out parameters in functions.

Regarding the in_numeric_value I like the numeric part but am not sure about the value part. A type or a concept is not a value. We do not have a is_arithmetic_value type trait in the standard for that reason. We just have is_arithmetic. We can rename Scalar to numeric but I am not sure if this a mathematically correct term too here?

[kwikius]

I must say that I am not a fan of an in_ prefix. During the discussions on the ISO C++ committee meetings, I suggested leaving any_ prefix for concepts. However, the quorum was to use it for polymorphic wrappers disappointed in_ is really misleading and clashes with the convention of prefixing in and out parameters in functions.

The first issue to deal with is that the committee needs to review their decision to rule out a common way to identify standard concepts within the lowercase constraint ( lowercase constraint which I find entirely justifiable). The units library is a good example of why there needs to be a simple way to identify concepts, since it uses many concepts ( probably more than any other standard library)

[kwikius]

Regarding the in_numeric_value I like the numeric part but am not sure about the value part. A type or a concept is not a value. We do not have a is_arithmetic_value type trait in the standard for that reason. We just have is_arithmetic. We can rename Scalar to numeric but I am not sure if this a mathematically correct term too here?

Probably we need to start by rigorously defining what these Concepts are meant to do...

[mpusz]

The units library is a good example of why there needs to be a simple way to identify concepts, since it uses many concepts ( probably more than any other standard library)

As promised I discussed this privately with Herb Sutter and @foonathan (http://wg21.link/p1851). Unfortunately, we stuck at some point and were not able to reach a consensus. Jonathan was suggesting to limit the number of concepts we use in the library. I was opposed to most cases...

[foonathan]

I'll take a closer look at your conflicts tomorrow. Maybe we can come up with suitable alternative names.

[mpusz]

Thanks, @foonathan. I wouldn't bother you if I did not believe this is a new kind of concepts important for accounting in our naming guidelines. Please see a full discussion in #93.