Skip to content

Conversation

@AudaciousAxiom
Copy link
Contributor

Description

This attempts to clarify in the std documentation how signed integers (i8i128 and isize) are encoded. I do not mean this to introduce a new stability guarantee, but only to document an already obvious (?) property, which is already documented elsewhere (mostly).

Motivation

My understanding is that signed integers are already guaranteed to be encoded in two's complement. The Reference does state this for i8i128 (but technically does not for isize, at least not in the same place), and in documenting numeric casts and negation operators:

Remember that signed integers are always represented using two’s complement.

This therefore does not seem architecture or platform-dependent. However it is also not specified explicitly in the FLS.

In addition, I could not find this in the std documentation, while this seems required to understand the behavior of shr operations and of as casts in particular.

If this is something you think is worth documenting explicitly, the exact phrasing can likely be refined (it is currently modeled on floats'). If not, feel free to close this PR.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 22, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 22, 2025

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@RalfJung
Copy link
Member

RalfJung commented Oct 24, 2025

Yeah this is definitely guaranteed. I don't have a strong opinion on whether it makes sense to repeat lang-level guarantees in the libs docs.

while this seems required to understand the behavior of shr operations and of as casts in particular.

I would argue that as casts should be specified in a way that the representation doesn't matter (and we do it that way in MiniRust): an int-to-int as cast simply takes the input operand as mathematical value, brings that value in-bounds of the output type if needed, and then returns that mathematical value as result. This spec elegantly covers all cases without having to do a case distinction: truncation, extension, and both types having the same size.

But I understand that currently that's not how we specify as, unfortunately.

Cc @traviscross

@traviscross traviscross added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. I-lang-docs-nominated Nominated for discussion during a lang-docs team meeting. labels Oct 24, 2025
@traviscross
Copy link
Contributor

traviscross commented Oct 24, 2025

Regarding this PR specifically, even though I see that we do something a bit like this for floats, I'd prefer to not cram this bit of information into the summary line of the doc comment for the type. Putting it in the body does seem OK though.

r? traviscross

cc @ehuss

My understanding is that signed integers are already guaranteed to be encoded in two's complement. The Reference does state this for i8i128 (but technically does not for isize, at least not in the same place)

Are you interested in making a PR to the Reference here to more cleanly make this guarantee? Probably I'd like to see the Reference guarantee this clearly before we do it in the standard library in this case.

@rustbot rustbot assigned traviscross and unassigned joboet Oct 24, 2025
@traviscross traviscross added the S-waiting-on-documentation Status: Waiting on approved PRs to documentation before merging label Oct 24, 2025
@traviscross
Copy link
Contributor

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 24, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 24, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@AudaciousAxiom
Copy link
Contributor Author

Are you interested in making a PR to the Reference here to more cleanly make this guarantee? Probably I'd like to see the Reference guarantee this clearly before we do it in the standard library in this case.

That makes sense, opened rust-lang/reference#2064 to this end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

I-lang-docs-nominated Nominated for discussion during a lang-docs team meeting. I-lang-radar Items that are on lang's radar and will need eventual work or consideration. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-documentation Status: Waiting on approved PRs to documentation before merging T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants