Promise array::from_fn is generated in order of increasing indices
#139099
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
scottmcm
added
T-libs-api
rustbot
added
the
S-waiting-on-review
scottmcm
added
the
S-waiting-on-team
scottmcm
changed the title
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. |
rfcbot
added
the
proposed-final-comment-period
Amanieu
removed
the
I-libs-api-nominated
rfcbot
added
disposition-merge
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
removed
the
proposed-final-comment-period
scottmcm
added
S-waiting-on-fcp
rfcbot
added
finished-final-comment-period
|
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 |
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 9, 2025
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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 9, 2025
…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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 9, 2025
…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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 9, 2025
…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
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 9, 2025
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.
github-actions bot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Apr 19, 2025
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_revor 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.