Constify MapWhile

[Randl]

This is part of an attempt to fully constify Iterator. Specifically, I'm extracting the changes from the local branch that contains more or less minimal Iterator constification. While MapWhile itself is not very important, it is a good way to make sure impl_fold_via_try_fold works properly with const.

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[Randl]

@rustbot ready

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tgross35]

Thank you for the interest! However, this falls under changes we don't want prior to a const trait RFC #155816:

Giving nightly users more const API is not sufficient reason to constify a trait or impl at this time, nor is checking off impls from a list.

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Randl]

Motivation is to constify Iterator eventually. It would require constifying impl_fold_via_try_fold and some of the bigger adapters that use it eventually.

I didn't want to make change to macro without using it anywhere, but I also didn't want constifying one of the bigger adapters in the same PR. I can do either if that's preferable @tgross35

[JohnTitor]

Oh, I wasn't aware of that, sorry. r? tgross35 for further review

[rustbot]

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

[Randl]

ping @tgross35
The change in impl_fold_via_try_fold is needed for const Iterator. MapWhile is a sample adapter to test these changes without large extra diff.

[tgross35]

Motivation is to constify Iterator eventually

So, this is specifically one of the things forbidden by the policy. We need a few methods in Iterator to be const to understand fthe language implications, but we don't need every method in the trait.

This change is small, but the policy exists largely because small changes add up. I don't think there is any reason to merge this before an accepted const trait RFC, so:

@rustbot blocked

[Randl]

I see

Since impl_fold_via_try_fold blocks most adapter-related things (and some others too), I thought this was important enough to include under the policy. Same with FromIterator in #161500, which is ubiquitous when working with iterators. I'd say it's hard to judge const Iterator without these.

A separate question is whether we're comfortable with stabilizing const traits while keeping #[rustc_non_const_trait_method] hack in the code. Iterator is a large trait, but I feel it's less of a burden than keeping the "non-const methods in const traits" feature.

[tgross35]

I'd say it's hard to judge const Iterator without these.

Before having an RFC, we're not trying to judge Iterator as a library item, but rather as a *languageitem..next()` and a few other methods are all we really have for that, nothing else is much more unique than any other code.

A separate question is whether we're comfortable with stabilizing const traits while keeping #[rustc_non_const_trait_method] hack in the code. Iterator is a large trait, but I feel it's less of a burden than keeping the "non-const methods in const traits" feature.

I don't know if it's a hack as much as lack of syntax, we'll probably have a way to do that eventually. I'm not concerned about using it because we'd likely want to keep the door open for methods that can't be const anyway.