[basic.types.trivial] New definition of "value" breaks `has_unique_object_representations<float>` and floating-point promotion

[eisenwave]

Reference: [basic.types.trivial]

Issue description

The new definition of "value" in P2434R4 is as follows:

Each trivially copyable type T has an implementation-defined set of discrete values. Each possible value representation of an object of type T corresponds to a distinct implementation-defined subset of this set. These subsets for a type are disjoint, and their union is the set of values; for scalar types other than object pointer types, each contains no more than one value.

Thus for "scalar types other than pointer types", every value representation corresponds to exactly one value (or no value, meaning that the representation is invalid, but that wouldn't change the result of has_unique_object_representations anyway). This is a breaking change for floating-point types because currently, every major compiler accepts the following code:

// Assuming float has the same representation as std::float32_t
static_assert(not std::has_unique_object_representations_v<float>);

Presumably, this is because the single NaN value has a variety of representations (different payloads). This interpretation is also supported by P3938R1 and has strong consensus in SG6 (see discussion during Brno meeting).

By the new definition of "value", unless std::float32_t had padding bits, std::has_unique_object_representations_v<std::float32_t> would have to be true because there is a bijective mapping between values and object representations ([meta.unary.prop]).

Additionally, the new definition of "value" makes floating-point promotion from float to double unimplementable because this conversion requires that "the value is unchanged" ([conv.fpprom]). If every NaN payload corresponds to a distinct value, it is impossible not to change the value when widening the mantissa during the conversion of float to double. That is, changing the amount of payloads bits should be considered a change in payload, and thus a change in value according to [basic.types.trivial].

Suggested resolution

Change the definition of "value" in [basic.types.trivial] as follows:

 Each trivially copyable type T
 has an implementation-defined set of discrete values.
 Each possible value representation of an object of type T
 corresponds to
-a distinct
+an
 implementation-defined subset of this set.
-These subsets for a type are disjoint,
-and their union is the set of values
-; for scalar types other than object pointer types,
-each contains no more than one value.
 Certain operations cause an object to acquire a value representation,
 in which case the object’s value is replaced
 with an unspecified member of the corresponding subset
 that would result in the program having defined behavior, if any.

[eisenwave]

I could also absorb this fix into https://isocpp.org/files/papers/D4287R0.html, but this defect seems somewhat unrelated to be honest.

[languagelawyer]

Sry, I do not get how striking

for scalar types other than object pointer types, each contains no more than one value

helps. P2434R4 says that each representation maps to subset of values, and the subsets are disjoint. This sentence says that for most scalar types, the set is of size 1.

What you need is to make sets not disjoint. So that NaN had many representations.

[eisenwave]

Yeah, thanks. I think the current solution works, though it's deleting quite a bit, and I'm not 100% sure if we're not yeeting out something important for pointers.

[safocl]

Each possible value representation of an object of type T corresponds to a distinct implementation-defined subset of this set.

So now, on the contrary, one value representation can mean multiple values? Doesn't this completely break the functionality of types in the standard?

If votes are counted here, then I'm against it. :)

[eisenwave]

So now, on the contrary, one value representation can mean multiple values? Doesn't this completely break the functionality of types in the standard?

Well, that's kinda the status quo. One pointer value representation can correspond to either an object pointer or to a past the end pointer (and both would have the same value representation). The paper doens't change that; it's always been like that.

And the paper has been merged into C++29, so it's too late to vote against.

[jensmaurer]

What was approved is R5, not R4, of the paper. And we struck "disjoint" during CWG review; see e.g. here: cplusplus/draft#9148

Please, instead of issuing a rapid-fire sequence of CWG issue submissions and/or paper drafts, take a moment to research the status quo.

[languagelawyer]

one value representation can mean multiple values?

You must've missed #931

[eisenwave]

@jensmaurer Oops, I did miss the next revision, however, R5 doesn't actually fix the issue.

The R5 wording is still broken because it requires that the subsets are "distinct". If every bit pattern corresponds to a distinct set (that is, a set that is not equal to other sets), it's still effectively required for every bit pattern to correspond to one value, and we end up with the same problem.

[jensmaurer]

The purpose of striking "disjoint" was to allow multiple value representations for the same value, I believe. I agree the "distinct" feels like a leftover from when we had "disjoint". I'll create a core issue for that limited scope (striking the single word) after the straw polls have been applied to the Working Draft.

@opensdh, do you remember why we left "distinct" in?