-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Cleanup: Use #![feature(associated_type_bounds)]
where applicable
#61738
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: