-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
opaque type definition: strict lifetime equality vs equal-by-inference #113971
Copy link
Copy link
Closed
Labels
A-impl-traitArea: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.F-type_alias_impl_trait`#[feature(type_alias_impl_trait)]``#[feature(type_alias_impl_trait)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-impl-traitArea: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.F-type_alias_impl_trait`#[feature(type_alias_impl_trait)]``#[feature(type_alias_impl_trait)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
The following code compiles but I don't think it should:
Here we have a defining use of an opaque type
Opaque<'_> == u8with a questionable legality. Let's call the inferred lifetime'?1.At each defining use of an opaque type, we require its lifetime arguments (
['?1]) to be equal to one of the lifetime parameters in scope (in this case there is only'x). This defining use passes this check becauseensure_outlivesregisters a region constraint'?1: 'x, and, because we infer the least possible value for lifetime variables, we end up inferring'?1 == 'x.The current situation is fine in regard to borrowck soundness (which is the reason we have such check in the first place) but it requires a subtle reasoning of lifetimes and makes the code more fragile (more on that later). For these reason, I believe we should enforce a stricter form of equality that requires both constraints
['x: '?1, '?1: 'x]in order to consider the lifetimes equal. It would be backward-compatible to change that later.To demonstrate how fragile the current behavior can be, here is a couple of trivial changes that break the original example.
'?1: 'xconstraint is no longer generated atensure_equal:cc @rust-lang/nitiative-impl-trait