about summary refs log tree commit diff
path: root/compiler/rustc_errors/src
diff options
context:
space:
mode:
authorMatthias Krüger <476013+matthiaskrgr@users.noreply.github.com>2025-04-09 14:52:37 +0200
committerGitHub <noreply@github.com>2025-04-09 14:52:37 +0200
commit4d1a63975c145df7722230820a876ddab0b06fd8 (patch)
tree1fe676258622dddfd1cf6a5f26e9f7f34afe3e30 /compiler/rustc_errors/src
parent19d4d9f371ac02c5861133f4081fb494269a9faa (diff)
parent6a915967f1d0033ce9e1a920885829d9ffe32716 (diff)
downloadrust-4d1a63975c145df7722230820a876ddab0b06fd8.tar.gz
rust-4d1a63975c145df7722230820a876ddab0b06fd8.zip
Rollup merge of #139099 - scottmcm:from_fn_docs, r=Amanieu
Promise `array::from_fn` is generated in order of increasing indices

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.
Diffstat (limited to 'compiler/rustc_errors/src')
0 files changed, 0 insertions, 0 deletions