-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup: Use #![feature(associated_type_bounds)]
where applicable
#61738
Comments
Shouldn't this wait for the feature to reach beta? |
Either works for me. |
@rustbot claim I'll implement this now, you can decide whether you want to merge it now or wait until it's stabilized. We could also make an issue to remove the |
Do you guys prefer: impl<T> Clone for ...<T>
where T: IntoIterator<IntoIter: Clone> or impl<T: IntoIterator<IntoIter: Clone>> Clone for ...<T> I like for former better. |
@iluuu1994 The first one should be: impl<T> Clone for ...<T>
where
T: IntoIterator<IntoIter: Clone>, per rustfmt. which one you use is situational I think; I'd use the latter if it cleanly fits on one line and there are not a lot of bounds and the former otherwise. |
Is this one expected to fail? pub struct Flatten<I>
where
I: Iterator,
I::Item: IntoIterator,
{
inner: I::Item::IntoIter,
}
Not sure how |
Yeah that's ambiguous. |
Additionally, switching to associated type bounds requires more Without associated type bounds this is ok: pub struct Flatten<I>
where
I: Iterator,
I::Item: IntoIterator,
{
inner: <I::Item as IntoIterator>::IntoIter,
} This one isn't ok: #![feature(associated_type_bounds)]
pub struct Flatten<I>
where
I: Iterator<Item: IntoIterator>,
{
inner: <I::Item as IntoIterator>::IntoIter,
}
This one is ok: #![feature(associated_type_bounds)]
pub struct Flatten<I>
where
I: Iterator<Item: IntoIterator>,
{
inner: <<I as Iterator>::Item as IntoIterator>::IntoIter,
} Note the |
How so? Can't |
This seems similar to the bug in #61752 :(
Honestly I don't really sure why that is the case but it has been ambiguous since forever. :) |
Haha ok that works for me 🙂 |
@Centril Sorry, I need to get the PR that fixes that bug merged soon. Niko left some feedback which I should address. Pester me tomorrow or the day after if I still haven't done it. |
Okay, #61919 is done, just waiting on review & merge. :-) |
…s, r=Centril Use associated_type_bounds where applicable - closes rust-lang#61738
…s, r=Centril Use associated_type_bounds where applicable - closes rust-lang#61738
…s, r=Centril Use associated_type_bounds where applicable - closes rust-lang#61738
…s, r=Centril Use associated_type_bounds where applicable - closes rust-lang#61738
Rollup of 7 pull requests Successful merges: - #63056 (Give built-in macros stable addresses in the standard library) - #63337 (Tweak mismatched types error) - #63350 (Use associated_type_bounds where applicable - closes #61738) - #63394 (Add test for issue 36804) - #63399 (More explicit diagnostic when using a `vec![]` in a pattern) - #63419 (check against more collisions for TypeId of fn pointer) - #63423 (Mention that tuple structs are private if any of their fields are) Failed merges: r? @ghost
We can now write bounds of form:
When you find bounds of form:
You can rewrite them to the first form (but you'll need to add the feature gate...).
One regex you can try is:
::\w+: \w+
(doesn't cover lifetimes).This is relevant both for the standard library and throughout the compiler.
Clippy may also want to do this and possibly also add an experimental lint? cc @oli-obk
cc #52662
This issue has been assigned to @iluuu1994 via this comment.
The text was updated successfully, but these errors were encountered: