Tracking Issue for relaxed struct unsizing rules

[lcnr]

The feature gate for the issue is #![feature(relaxed_struct_unsize)].

This features changes the when a struct implements Unsize which
is required for unsize coercion.

A generic struct previously implemented Unsize if and only if:

• the tail field depends on at least one type or const parameter
• all type and const parameters used in the last field must only be used in the last field
• the target struct can be created from the source by replacing only the parameters found in the last struct field
• the tail field implements Unsize from source to target

With this feature gate the requirements are changed to:

• the tail field depends on at least one type or const parameter not used in any other field
• the target struct can be created from the source by replacing only the parameters only found in the last struct field
• the tail field implements Unsize from source to target

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Implementation history

This feature has been implemented in #80726

[lcnr]

Nominating this feature for stabilization. I don't see much use in keeping this unstable and consider this change to be a simplification and improvement of our current rules.

The two relevant tests here are https://github.com/rust-lang/rust/blob/master/src/test/ui/unsized/unchanged-param.rs and #88357.

[lcnr]

Stabilization report

This is the stabilization report for #![feature(relaxed_struct_unsize)], which slightly improves the rules for struct unsizing.

Summary and Explanation

A generic struct previously implemented Unsize if and only if:

• the tail field depends on at least one type or const parameter
• all type and const parameters used in the last field must only be used in the last field
• the target struct can be created from the source by replacing only the parameters found in the last struct field
• the tail field implements Unsize from source to target

With this feature gate the requirements are changed to:

• the tail field depends on at least one type or const parameter not used in any other field
• the target struct can be created from the source by replacing only the parameters only found in the last struct field
• the tail field implements Unsize from source to target

Example

#![feature(relaxed_struct_unsize)]
struct A<T, U: ?Sized + 'static>(T, B<T, U>);
struct B<T, U: ?Sized>(T, U);

fn main() {
    let x: A<[u32; 1], [u32; 1]> = A([0; 1], B([0; 1], [0; 1]));
    // This previously did not work as the last field of `A` also mentions `T`,
    // as only `U` changes this is now allowed thanks to this feature.
    let _y: &A<[u32; 1], [u32]> = &x;
}

Motivation

This feature changes the existing rules to be more intuitive and more permissive. We also assume it to not cause any future compatibility issues as there is no known sensible improvement to struct unsizing which is prevented by this change.

An example where the current rules are inadequate which is fixed with this feature: playground

// you can unsize `U` without this feature, but
struct A<T, U: ?Sized + 'static>(T, T, U);

// after extracting the last 2 fields, you cannot unsize `U` anymore.
struct A<T, U: ?Sized + 'static>(T, B<T, U>);
struct B<T, U: ?Sized + 'static>(T, U);

Unsizing is a fairly unknown area of Rust where mistakes cause very unhelpful errors. This makes improvements to its rules especially worthwhile.

[pnkfelix]

@rfcbot fcp merge

[rfcbot]

Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.