Skip to content
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

Tracking Issue for const_intoiterator_identity #90603

Open
1 of 3 tasks
mbartlett21 opened this issue Nov 5, 2021 · 4 comments
Open
1 of 3 tasks

Tracking Issue for const_intoiterator_identity #90603

mbartlett21 opened this issue Nov 5, 2021 · 4 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@mbartlett21
Copy link
Contributor

mbartlett21 commented Nov 5, 2021

Feature gate: #![feature(const_intoiterator_identity)]

This is a tracking issue for the const IntoIterator implementation for types that are already iterators.

This is not a new api; only constifying an existing one

Public API

// core::iter
// actually core/iter/traits/collect.rs, but re-exported from there.
impl<I: ~const Iterator> const IntoIterator for I {
    type Item = I::Item;
    type IntoIter = I;
    fn into_iter(self) -> I;
}

Steps / History

Unresolved Questions

  • Should it bound on the resultant Iterator being a const Iterator or not? I've gone with having the bound for now. Note: This can be relaxed later without breaking any code.
@mbartlett21 mbartlett21 added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 5, 2021
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 23, 2022
…-obk

Unstably constify `impl<I: Iterator> IntoIterator for I`

This constifies the default `IntoIterator` implementation under the `const_intoiterator_identity` feature.

Tracking Issue: rust-lang#90603
@zakarumych
Copy link
Contributor

Why would it have I: ~const Iterator bound instead of I: Iterator?

@mbartlett21
Copy link
Contributor Author

See #90602 (comment).
Basically, it makes it compatible with whether the IntoIterator trait gets a bound or not, and if it doesn't get a bound, this implementation can always be loosened later.

@zakarumych
Copy link
Contributor

Not sure I follow.
It's conservative and can be relaxed later - I get this part.
What is motivation to not relax it right away?

@mbartlett21
Copy link
Contributor Author

mbartlett21 commented Aug 9, 2022

It was a decision that could be changed later, so I just chose a choice and went with that. Either way, that's a question that can come up when the actual trait gets changed (or not) and const impls are stabilised.

The motivation is that there was also no motivation to go the other way either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants