search

rust-lang / reference

The Rust Reference
https://doc.rust-lang.org/nightly/reference/
Apache License 2.0
1.25k stars 491 forks source link

Add Values and Representation chapter #1664

Open chorman0773 opened 1 month ago

chorman0773 commented 1 month ago

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.

traviscross commented 2 weeks ago

@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.

traviscross commented 2 weeks ago

cc @rust-lang/lang

chorman0773 commented 2 weeks ago

Can we move these rules into those chapters (and avoid any duplication with things that are already there)?

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).

chorman0773 commented 4 days ago

Need to figure out how to disentangle the aggregate representation rules to move them into a separate chapter.

chorman0773 commented 3 days ago

@rustbot ready

chorman0773 commented 21 hours ago

Just talked about this on the Community Discord, apparently there is one guarantee this makes that is "new". Namely, it guarantees that wide pointers are represented like some repr(Rust) struct of the data pointer and its metadata. While this seems like it's doing nothing, one thing it does say is that the fields exist somewhere in the representation (and the compiler isn't doing far more interesting shenanigans than it might do to a tuple or a struct). Is this a problematic guarantee to make?