Add Values and Representation chapter #1664
Conversation
chorman0773
added
S-waiting-on-review
| A floating-point value consists of either a rational number, which is within the range and precision dictated by the type, an infinity, or a NaN value. | ||
|
|
||
| r[value.primitive.float-repr] | ||
| A floating-point value is represented the same as a value of the unsigned integer type with the same width given by its [IEEE 754-2019] encoding. |
There was a problem hiding this comment.
We looked at this one sentence in particular in our lang-docs call today, and we were having a lot of trouble parsing it. Perhaps you could say this another way for us to better understand the intent here. Why does this need to reference "an unsigned integer type of the same width" at all, e.g.?
There was a problem hiding this comment.
It's to inherit the definition of endianess from unsigned integer types (where its the easiest to define). Signed integers also do the same thing.
|
@rust-lang/opsem: We're interested in your review on this. From the lang-docs side, we're particularly interested to confirm that this text is both correct from your perspective and is not making an new guarantees about the language. |
|
cc @rust-lang/lang |
There was a problem hiding this comment.
I'm feeling uncertain about this approach of having a chapter specifically for these representations. In the past, we have placed these definitions in the chapters for the types they are defining (for example, the char chapter defines the char). Can we move these rules into those chapters (and avoid any duplication with things that are already there)?
| r[value.pointer] | ||
|
|
||
| r[value.pointer.thin] | ||
| Each thin pointer consists of an address and an optional provenance. The address refers to which byte the pointer points to. The provenance refers to which bytes the pointer is allowed to access, and the allocation those bytes are within. |
There was a problem hiding this comment.
This starts using the term provenance without defining what it means. Would it be possible to at least start that in the glossary? I'm also not sure if we'll need a more elaborate introduction, since rfc#3559 is quite weighty, so maybe there will need to be a more dedicated section for that?
There was a problem hiding this comment.
There will be eventually, but it also an incredibly weakly defined topic right now. The main definition we have today is frankly, "It exists". Anything more requires a ton more litigation from T-opsem. Defining a byte requires referring to provenance, though, at least in the most abstract sense.
There was a problem hiding this comment.
I added as much as is really decided.
We still have to define what a byte is, which is relatively small for its own chapter, but doesn't have any other chapter to go in (glossary shouldn't provide normative definitions). It's also going to duplicate content excessively for aggregate types, since tuples and structs have different chapters, but have the exact same values and representation (according to a particular layout). |
This documents the values for most types (where it has been decided), as well as the representation of these values in memory. It also defines what a byte is in Rust (including initialized and uninitialized memory).
The chapter does not define what Provenance carries in Rust.
repr(Rust)enums are also not fully elaborated, as there are things undecided.This makes a normative reference to https://ieeexplore.ieee.org/document/8766229 for floating-point format.