On Wed, Aug 28, 2019 at 5:44 PM Tony V E <tvaneerd_at_[hidden]> wrote:

> I don't think the definition of value has much, if anything, to do with
> bits.
>

Whereas I think the definition of value has only to do with bits.
That's because I prefer the "bag of bits" model to the "object" model.

My preferred model is:
1) An object is a region of storage and a type for interpreting its
contents (which may include an alignment requirement).
2) A type has a contiguous object representation and a subset, possibly
non-contiguous, value representation.
3) The value of a typed object is the sequence of bits in its value
representation.
4) Two typed objects have the same value if their value representation is
the same.
5) Having the same value does not imply anything about what comparison
operators must report. Two typed objects with different value
representations may be == (e.g., +0.0 and -0.0) and a typed object may be
not == to itself (e.g., NaN).
6) The same region of storage may be interpreted using any number of
types. (Therefore there is no "strict aliasing" prohibition. Union type
punning is fine too.)
7) Certain operations on objects (generally related to virtual dispatch)
rely on implementation-defined parts of the value representation being
properly set up by constructors and destructors. Setting those parts up
independently, in an implementation-defined way (say by using memcpy on the
region of storage) results in objects that behave in the same way on those
operations.
8) Types may have invariants that constrain values against addresses with
respect to the region of storage, so that of two typed objects with the
same value, one may meet its constraints while the other does not.
9) Uninitialized storage has arbitrary but consistent contents, so that it
may be read and the same value will be read each time if read more than
once.

(I don't care what words are used, so if you don't like "same" or "value",
that's fine. Other words will do.)