Repository navigation
Reject bounds in type aliases in a future edition #49441
Description
Activity
We can make it a hard error instead, fwiw.
We can make it a hard error instead, fwiw.
I thought deny-by-default-lint was as hard as we wanted to make things in the next edition, but yeah -- there is no good reason to still allow this code, other than to ease porting to the next edition by allowing the lint.
Would that mean this is a topic for rustfix?
Yes -- edition breakages work by taking a warn lint in a certain group and making it a hard error; and having a good suggestion that rustfix can apply
@nikomatsakis you mentioned some plans to fix where clauses in type aliases properly, so that they are added as obligations when type aliases are expanded. What is the status of that? I think this lint should become an error in the next edition, but whether it becomes Deny-by-default or a hard error I guess depends on whether we need this to be rule out for a transition in the 2021 edition.
After some talking with @Centril, I think ideally we want a lint that
- complains about
type SendVec<T: Send> = Vec<T>because the bound is ignored - complains about
type Baz<I> = <I as Iterator>::Itembecause associated items should have a bound - does not complain about
type Baz<I: Iterator> = <I as Iterator>::Itembecause the bound is, de facto, enforced after expansion.
What makes this hard is that associated items are not the only way that a bound can be used; using a type like
struct Foo<T: Send>(T)is another way -- but @eddyb said he had ideas.Reacted by Mazdak Farrokhzad- complains about
My idea is to diff what WF needs (i.e. the things that would error if not satisfied) with the predicates (bounds) written by the user.
Without Chalk this will be tricky, but we can manually run trait selection (or just plug something optional into the fulfillment context) to peek at how each WF requirement is satisfied, and mark every predicate that actually ends up used as part of that process, as useful - everything else, we'll warn (we can even have a consistency check, that if we remove the "unused bounds", WF still passes).EDIT: Hang on, we might be able to do "difference" much easier by trying every declared bound with WF bounds as assumed: if they fail, that means the WF conditions enforced onto the user of the type alias aren't enough to subsume it, which is really what we want to check for (equivalence)!
We actually have a very good reason to check "WF of RHS implies bounds" and not "used":
type DEIItem<T: DoubleEndedIterator> = T::Item;
The
DoubleEndedIteratorbound won't be checked in uses, onlyWF(T::Item)i.e.T: Iteratorwill.
And whenever we can start checking uses, then we don't really care if the bounds are used.I guess this is the same problem I recognized last year (#44075 (comment)), but now I have a plan.
37 remaining items
- changed the title
[-]Reject bounds in type aliases with edition 2018[/-][+]Reject bounds in type aliases with edition 2024[/+]on Nov 15, 2023 Since I see this being considered for edition 2024, I'll note that this lint fires on lifetime bounds which, while not enforced, are also not inert. In summary, if you want the below alias to behave like
&Tbehaves with regards todynlifetime defaults, you need the bound (and removing the bound can break code relying on it).pub type Borrow<'a, T: 'a> = &'a T; // With the bound, `Borrow<'a, dyn Trait>` is `&'a (dyn Trait + 'a)` // Without the bound, it is `&'a (dyn Trait + 'static)`
I.e. this applies to alias definitions in addition to
struct(etc) definitions.- changed the title
[-]Reject bounds in type aliases with edition 2024[/-][+]Reject bounds in type aliases a future edition[/+]on Jul 24, 2025 - changed the title
[-]Reject bounds in type aliases a future edition[/-][+]Reject bounds in type aliases in a future edition[/+]on Sep 2, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
View all comments
I propose to make the
type_alias_boundslint deny-by-default with the next edition. See #21903 for more information on the issue being linted, and #48326 and #48909 for the PRs implementing the lint.Cc @nikomatsakis @Manishearth (and Manish told me to also Cc someone else but I forgot whom)