Add integer truncation and extension methods

[joshtriplett]

View all comments

Tracking issue: #154330

This provides .truncate(), .saturating_truncate(), .checked_truncate(), and .extend().

These only work within the same signedness (use .cast_signed() and .cast_unsigned() to change sign).

The truncation methods only work to smaller (or equal) types. .extend() only works to larger (or equal) types.

For the purposes of truncation and extending, nothing is considered larger than or equal to the size of usize, and usize is considered larger than u16 or u8. We might, in the future, want to consider ways to expand this.

Much of this was pair-programmed with @Amanieu.

In order to seal the new traits, this PR also adds a core::sealed::Sealed, like the one in std. I didn't modify std to re-export the same one, since by definition it isn't nameable, and since doing that would require that it be nameable (even if it was #[unstable]).

[rustbot]

r? @scottmcm

rustbot has assigned @scottmcm.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @scottmcm, libs
• @scottmcm, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, scottmcm

[joshtriplett]

r? jhpratt

[juntyr]

Has Rust guaranteed before that [u|i]size will always be smaller than 128bit?

[joshtriplett]

@jhpratt I added const trait support.

I didn't end up squashing it, because it was sufficiently fiddly that I think there's genuine value in having it as a separate commit from the initial implementation.

Would you mind checking it, and r+ing if you think it looks reasonable? (Not applying your r=me because you had said to squash it first.)

[jhpratt]

I'll take a look at this in the coming day! It is worth double-checking the usize/u128 thing; I actually don't know the answer to that.

[jhpratt]

Imo this could be reduced some, but not necessarily to a single commit

• Introduce sealed trait
  • Implementing it could stay its own, but personally I'd probably combine it
• Adding the new methods, merging in the test update and size_of nit
• Constifying them

And after looking, usize/isize do not implement From for 128 bit integers, so those should be left out. Although that's presumably what this is nominated for?

[joshtriplett]

@jhpratt I've rebased this, squashing in the fixes to previous commits.

And yes, the libs-api nomination is to evaluate the implementations allowing conversion between u128 and usize. (Frankly, I think we ought to evaluate the possibility of conditional implementations between u64 and usize, but that's a separate matter for another day.)

[jhpratt]

Works for me. Conditional implementations could work, but would prove hazardous to libraries that try to work across platforms. To the extent that there would probably be a clippy lint for relying on such an implementation.

[joshtriplett]

@jhpratt We discussed this in today's @rust-lang/libs-api meeting. We agreed to drop the u128 impls for now, so this should be ready to merge.

We also talked about strategies for shipping the conditional impls (for these and for From/Into), but that can happen separately.

[jhpratt]

Perfect. Happy to finally see this uplifted!

@bors r+ rollup

[rust-bors]

📌 Commit 68c8339 has been approved by jhpratt

It is now in the queue for this repository.

[Mark-Simulacrum]

@rust-timer build e6fe002

[rust-timer]

Finished benchmarking commit (e6fe002): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.4%]	4
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	12
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.1%, 0.4%]	4

Max RSS (memory usage)

Results (primary 1.0%, secondary 0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.6%, 1.5%]	2
Regressions ❌ (secondary)	1.5%	[1.5%, 1.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.0%	[-1.0%, -1.0%]	1
All ❌✅ (primary)	1.0%	[0.6%, 1.5%]	2

Cycles

Results (secondary -4.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-6.0%, -2.2%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 483.835s -> 483.687s (-0.03%)
Artifact size: 394.92 MiB -> 394.92 MiB (0.00%)

[RalfJung]

We agreed to drop the u128 impls for now, so this should be ready to merge.

Friendly reminder to please update the PR description when the nature of a PR is changed like that. :) Ideally this happens before landing since the PR description ends up in the git history.