Skip to content

array::from_fn behavior unclear from documentation #139061

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.

Sign up for GitHub

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

Jump to bottom
Closed
SyxtonPrime opened this issue Mar 28, 2025 · 0 comments · Fixed by #139099
Closed

array::from_fn behavior unclear from documentation #139061

SyxtonPrime opened this issue Mar 28, 2025 · 0 comments · Fixed by #139099
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@SyxtonPrime
Copy link

Location

https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html

Summary

Currently the documentation surrounding array::from_fn does not guarantee the order in which the array items are generated. Given that it accepts an FnMut this seems dangerous. For example, code such as:

let mut iter = 0..5;
let arr = core::array::from_fn(|_| iter.next().unwrap());
assert_eq!(arr, [0, 1, 2, 3, 4]);

currently compiles as expected but would fail if array::from_fn constructed the array out of order.

The documentation should be updated to either confirm that the code above is a valid use of array::from_fn or to warn users that elements may be generated out of order.

This was previously mentioned in the discussion around #102609 but didn't end up getting fixed.
@SyxtonPrime SyxtonPrime added the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Mar 28, 2025
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 28, 2025
@jieyouxu jieyouxu added T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Mar 28, 2025
@SyxtonPrime SyxtonPrime mentioned this issue Mar 28, 2025
Closed
@scottmcm scottmcm mentioned this issue Mar 29, 2025
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 9, 2025
@matthiaskrgr
Rollup merge of rust-lang#139099 - scottmcm:from_fn_docs, r=Amanieu
dd0d9ad 
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 bors closed this as completed in 4d1a639 Apr 9, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 9, 2025
@rust-timer
Unrolled build for rust-lang#139099
3e9f985 
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 issue Apr 19, 2025
@matthiaskrgr
Rollup merge of rust-lang#139099 - scottmcm:from_fn_docs, r=Amanieu
d904053 
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
Assignees
No one assigned
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Promise array::from_fn is generated in order of increasing indices scottmcm/rust
3 participants
@SyxtonPrime @jieyouxu @rustbot