[temp.type] Replace "values are identical" with "value representations are identical"

[eisenwave]

This fixes a really confusing bit of terminology:

• for integral types, values are template-argument-equivalent if they are "the same"
• for floating-point types, values are template-argument-equivalent if they are "identical"

It is not obvious what the distinction between "same" and "identical" is, given that these are synonyms.

However, the CWG intent is clear on this:

• https://wg21.link/p1714r1 talked about identical value representations, but the paper was rejected.
• https://wg21.link/p1907r1 implemented those changes in response to C++20 NB comments in an omnibus paper that solves a bunch of NB comments. While the wording is different, the design intent is still to implement P1714R1.

@jensmaurer the latter is your paper by the way.

[frederick-vs-ja]

See #4600 (comment). It seems that some implementors want to use normalized values for identity.

Perhaps we should copy some wording from C (in e.g. WG14 N3220 5.2.5.3.3) and additional say

• it's implementation-defined whether the "possibly normalized value representations" (for an unnormalized value equal to normalized one, representation of the normalized one is used instead) or the original value representations are used for comparison.

[eisenwave]

I've checked the minutes on these papers and was unable to find any evidence that there is design intent to perform normalization for template argument equivalence.

Unless proven otherwise, I'm just going to claim that the intent is to do what P1714R1 does, and P1907R1 still has that intent, but with clunky wording.

@zygoloid was the idea of normalization for template argument equivalence discussed anywhere?

[jensmaurer]

As far as I can say, the "identical" (as opposed to "same value representation") here was intentional, also given #4600 (comment) . Since there might not be an "object" for a template parameter of floating-point type, it's questionable whether the term "value representation" would apply in the first place.

This is not editorial matter by far.

[eisenwave]

I guess I'll incorporate this in the omnibus paper that solves a bunch of the recent CWG issues on floating-point numbers.

I suppose the whole thing could be defined in terms of bit-casting somehow; all the evidence points towards implementations handling floating-point constant template arguments that way. Even different NaN payloads (which are clearly the same qNaN or sNaN value) result in distinct template specializations, so this idea that template argument equivalence tries to normalize floating-point numbers seems inconsistent with the status quo, and is purely hypothetical.

[jensmaurer]

I suppose the whole thing could be defined in terms of bit-casting somehow

Richard said something different here: #4600 (comment) :

There are environments in which the same number can be exactly represented as both a normalized and a non-normalized floating point value, with distinct value representations, and we did not intend to require that they be treated as different.

"There are" doesn't sound "purely hypothetical". And, in fact, IEEE decimal floating-point is one such environment. (There is no requirement that C++ floating-point be binary.)

[eisenwave]

"There are" doesn't sound "purely hypothetical". And, in fact, IEEE decimal floating-point is one such environment. (There is no requirement that C++ floating-point be binary.)

I understand that there formats with multiple representations of the same value. However, it seems purely hypothetical that any implementation is interested in normalizing these for template argument equivalence. It seems like there exists no implementation that does that, nor was it ever intended by EWG or CWG to happen.

I was unable to find any record of discussion on normalization being done here. P1714R1 was very clear about no such normalization being done; it explicitly talked about value representations, and there seems to have been no intention to change the design since then.

I think Richard was missing some context when he made that comment.

[eisenwave]

https://godbolt.org/z/ezWq1G4Ex See here for what I mean. I'm not sure how to test with EDG, but GCC, Clang, and MSVC all treat different NaN payloads (of the same value, which is sNaN) as producing distinct template instantiations, and they perform name mangling by just bit-casting to an integer and integrating that into the name somehow.