make field representing types invariant over the base type#154778
make field representing types invariant over the base type#154778rust-bors[bot] merged 2 commits intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
|
|
|
@rustbot label +F-field_projections |
|
@bors r+ rollup |
rust-bors
Bot
added
S-waiting-on-bors
oli-obk
added
S-waiting-on-review
…uwer Rollup of 15 pull requests Successful merges: - #153995 (Use convergent attribute to funcs for GPU targets) - #154184 (stabilize s390x vector registers) - #151898 (constify DoubleEndedIterator) - #154235 (remove unnecessary variables and delimiter check) - #154473 (move borrow checker tests) - #154745 (Replace span_look_ahead with span_followed_by) - #154778 (make field representing types invariant over the base type) - #154867 (Fix private fields diagnostics and improve error messages) - #154879 (Don't store `pattern_ty` in `TestableCase`) - #154910 (Suppress `unreachable_code` lint in `derive(PartialEq, Clone)`) - #154923 (Fix ICE in next-solver dyn-compatibility check) - #154934 (Add getters for `rustc_pattern_analysis::constructor::Slice` fields) - #154938 (match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness) - #154961 (Use derived impl for `GappedRange` subdiagnostic) - #154980 (rustc-dev-guide subtree update)
rustbot
removed
the
S-waiting-on-review
Rollup merge of #154778 - BennoLossin:frt-invariant, r=oli-obk make field representing types invariant over the base type We probably don't want to have any subtype relationship between any FRTs. Reported-by: @dvdhrm "David Rheinsberg" <[email protected]> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Multiple.20LockedBy.20with.20Single.20Lock/near/579275908 r? @oli-obk
|
Thanks a lot for changing this! I think this also needs to be a guarantee of the API, rather than just an implementation detail. If I create a generic type with an FRT, I want to be ensured that the FRT cannot be changed due to subtyping, as other parts of the object might rely on the metadata of the FRT to be immutable. IOW, I don't want an intrusive list |
|
Thanks a lot for noticing this mistake :) It makes a lot of sense to want this to be documented. Note that this feature is still unstable and incomplete. When we initially created FRTs, we thought we needed them for field projections. It turns out that we do not necessarily need them. I plan to keep them until we've fully verified this in the field projection experiment. Additionally, @fbq has expressed a need for FRTs for his intrusive data structure abstractions in RfL. If you also have a use for FRTs, we can think about splitting them off into a separate feature and write an RFC to get them stabilized orthogonally to field projections. When we do that, we can also document this guarantee (FRTs are invariant over the base type, and that different fields will result in different FRTs). If you want, you can file a PR to add a comment to |
…uwer Rollup of 15 pull requests Successful merges: - rust-lang/rust#153995 (Use convergent attribute to funcs for GPU targets) - rust-lang/rust#154184 (stabilize s390x vector registers) - rust-lang/rust#151898 (constify DoubleEndedIterator) - rust-lang/rust#154235 (remove unnecessary variables and delimiter check) - rust-lang/rust#154473 (move borrow checker tests) - rust-lang/rust#154745 (Replace span_look_ahead with span_followed_by) - rust-lang/rust#154778 (make field representing types invariant over the base type) - rust-lang/rust#154867 (Fix private fields diagnostics and improve error messages) - rust-lang/rust#154879 (Don't store `pattern_ty` in `TestableCase`) - rust-lang/rust#154910 (Suppress `unreachable_code` lint in `derive(PartialEq, Clone)`) - rust-lang/rust#154923 (Fix ICE in next-solver dyn-compatibility check) - rust-lang/rust#154934 (Add getters for `rustc_pattern_analysis::constructor::Slice` fields) - rust-lang/rust#154938 (match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness) - rust-lang/rust#154961 (Use derived impl for `GappedRange` subdiagnostic) - rust-lang/rust#154980 (rustc-dev-guide subtree update)
4 participants
We probably don't want to have any subtype relationship between any FRTs.
Reported-by: @dvdhrm "David Rheinsberg" [email protected]
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Multiple.20LockedBy.20with.20Single.20Lock/near/579275908
r? @oli-obk