-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Promise array::from_fn
is generated in order of increasing indices
#139099
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
Conversation
array::from_fn
in generated in order of increasing indicesarray::from_fn
is generated in order of increasing indices
There seems to be little downside to guaranteeing this. @rfcbot merge |
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Since this is (essentially) just a comment change, I think I can treat the libs-api FCP as a review of it. We can always make it more-better in later PRs. @bors r=Amanieu rollup=always |
Promise `array::from_fn` is generated in order of increasing indices Fixes rust-lang#139061 I agree this needs to be documented because of the `FnMut`, either with a guarantee or to explicitly disclaim one. I'm pretty sure this will be non-controversial (like the other "well sure you *could* do it in a different order, but why?" things were), but I couldn't find any previous libs-api decision on it so it's seemingly a new promise that will need FCP. Basically, yes, it would be plausible to fill in the reverse order, but there's no obvious way we could ever know that that might even be a good idea, so forward seems like an easy thing to promise. We could always add a `from_fn_rev` or something later if there's ever a strong enough need, but it seems unlikely. Let's just do the obvious thing so it matches what `[gen(0), gen(1), …, gen(N-1)]` does.
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#137412 (Ensure `swap_nonoverlapping` is really always untyped) - rust-lang#138869 (Try not to use verbatim paths in `Command::current_dir`) - rust-lang#138993 (Make `cfg_match!` a semitransparent macro) - rust-lang#139099 (Promise `array::from_fn` is generated in order of increasing indices) - rust-lang#139364 (Make the compiler suggest actual paths instead of visible paths if the visible paths are through any doc hidden path.) - rust-lang#139468 (Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`) - rust-lang#139481 (Add job summary links to post-merge report) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#138869 (Try not to use verbatim paths in `Command::current_dir`) - rust-lang#138993 (Make `cfg_match!` a semitransparent macro) - rust-lang#139099 (Promise `array::from_fn` is generated in order of increasing indices) - rust-lang#139364 (Make the compiler suggest actual paths instead of visible paths if the visible paths are through any doc hidden path.) - rust-lang#139468 (Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`) - rust-lang#139481 (Add job summary links to post-merge report) - rust-lang#139573 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#138869 (Try not to use verbatim paths in `Command::current_dir`) - rust-lang#138993 (Make `cfg_match!` a semitransparent macro) - rust-lang#139099 (Promise `array::from_fn` is generated in order of increasing indices) - rust-lang#139364 (Make the compiler suggest actual paths instead of visible paths if the visible paths are through any doc hidden path.) - rust-lang#139468 (Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`) - rust-lang#139481 (Add job summary links to post-merge report) - rust-lang#139573 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#139099 - scottmcm:from_fn_docs, r=Amanieu Promise `array::from_fn` is generated in order of increasing indices Fixes rust-lang#139061 I agree this needs to be documented because of the `FnMut`, either with a guarantee or to explicitly disclaim one. I'm pretty sure this will be non-controversial (like the other "well sure you *could* do it in a different order, but why?" things were), but I couldn't find any previous libs-api decision on it so it's seemingly a new promise that will need FCP. Basically, yes, it would be plausible to fill in the reverse order, but there's no obvious way we could ever know that that might even be a good idea, so forward seems like an easy thing to promise. We could always add a `from_fn_rev` or something later if there's ever a strong enough need, but it seems unlikely. Let's just do the obvious thing so it matches what `[gen(0), gen(1), …, gen(N-1)]` does.
Promise `array::from_fn` is generated in order of increasing indices Fixes rust-lang#139061 I agree this needs to be documented because of the `FnMut`, either with a guarantee or to explicitly disclaim one. I'm pretty sure this will be non-controversial (like the other "well sure you *could* do it in a different order, but why?" things were), but I couldn't find any previous libs-api decision on it so it's seemingly a new promise that will need FCP. Basically, yes, it would be plausible to fill in the reverse order, but there's no obvious way we could ever know that that might even be a good idea, so forward seems like an easy thing to promise. We could always add a `from_fn_rev` or something later if there's ever a strong enough need, but it seems unlikely. Let's just do the obvious thing so it matches what `[gen(0), gen(1), …, gen(N-1)]` does.
Fixes #139061
I agree this needs to be documented because of the
FnMut
, either with a guarantee or to explicitly disclaim one.I'm pretty sure this will be non-controversial (like the other "well sure you could do it in a different order, but why?" things were), but I couldn't find any previous libs-api decision on it so it's seemingly a new promise that will need FCP.
Basically, yes, it would be plausible to fill in the reverse order, but there's no obvious way we could ever know that that might even be a good idea, so forward seems like an easy thing to promise. We could always add a
from_fn_rev
or something later if there's ever a strong enough need, but it seems unlikely.Let's just do the obvious thing so it matches what
[gen(0), gen(1), …, gen(N-1)]
does.