Tracking issue for `try_array_from_fn` #89379

c410-f3r · 2021-09-29T22:04:33Z

Provides the common use-case of creating custom fallible arrays in a reliable and unified way. Particularly useful for elements that don't implement Copy, Clone or Default.

Public API

// Unstable
fn try_from_fn<E, F, T, const N: usize>(cb: F) -> Result<[T; N], E>
where
    F: FnMut(usize) -> Result<T, E>;

Steps / History

Implementation (Add 'core::array::from_fn' and 'core::array::try_from_fn' #75644)
Final comment period
Stabilization PR

Unresolved Questions

~~Should the callback return indices (Add 'core::array::from_fn' and 'core::array::try_from_fn' #75644 (comment)) ?~~
from_fn and try_from_fn are very similar to repeat_with and try_repeat_with (Tracking Issue for core::array::(try_)repeat(_with) (feature array_repeat) #91613), just that they take unary instead of nullary functions. Anyone considering stabilizing these should think about those, and vice versa.

The text was updated successfully, but these errors were encountered:

dtolnay · 2021-11-02T18:45:10Z

I am not certain the currently implemented signature of try_from_fn is the right one. The most similar thing to this currently in the standard library is https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.try_for_each, where the return type is a generic R based on a Try trait impl, instead of hardcoded to Result. Can try_from_fn be done the same way?

scottmcm · 2021-11-27T10:03:18Z

@dtolnay I've submitted a PR to update array::try_from_fn to be generic over Try types: #91286

(As well as other related methods like Iterator::try_find #63178 that hit similar questions.)

scottmcm · 2021-11-28T07:37:19Z

My 2¢ on the usize parameter question:

There's clearly a bunch of cases where it's handy, as @‍c410-f3r showed in Change array_from_fn signatures #90505 (comment)
It's easy to ignore it if you don't need it, like in array::from_fn(|_| value.clone()).
But tracking it yourself if the function doesn't when you do need it is a pain. ι being from_fn(identity) is so much tidier than { let mut i = 0; from_fn(|| { let temp = i; i += 1; temp }) } or whatever.
Unlike with iter::from_fn, a usize fundamentally can't overflow in array::from_fn. And iter::from_fn's closure must return an Option, so its signature will never match array::from_fn. (Though I guess array::try_from_fn can take -> Option closures, but with different semantics.)
Making it generic opens so many questions (like overflow) that I just don't see it happening in core. It could be done with Default + Step, but that's arguably a misuse of Default, and it also allows things like array::from_fn::<i8, 200> which feels wrong. I don't see core importing num_traits::Unsigned any time soon.
Making it generic would make it harder to ignore when you don't need it. It would be a shame to have to write array::from_fn(|_: usize| value.clone()), for example. It could potentially allow from_fn(|()| value.clone()), but that's non-obvious and makes the trait question even harder. (().. isn't an iterator, and I hope that stays the case.)
enumerate is precedent for "sometimes we only offer the usize version", so it's not unusual to only support usize here.
With TryInto in the prelude it's not that bad to get another type, and the range is obvious to LLVM in the monomorphization, so the checks easily optimize away.
It's almost certainly free to have the index. It's actually being maintained in the guard in collect_into_array anyway to know which things to drop. Not to mention that it has to write into the array, where if that's done with addressing modes like ptr [edx + 4*eax] then the counter's already there too. (And things'll probably get inlined enough anyway that it'd be easy to remove if unused. The only way it wouldn't would be if the closure if complex, but then the cost of 1 LEA is unnoticeable.)

So personally I think array::from_fn is right how it is, for all the reasons it ended up this way in the initial PR. And I'd like to see it move forward for stabilization. That's not up to me, though.

I don't think array::try_from_fn is ready yet, though, so I don't know how procedurally libs-api would like to go, here. Usually it FCPs in the tracking issue, but there can only be one FCP per issue/PR, so maybe for a partial one it'd need a separate issue or a stabilization PR in which to make the decision?

yoshuawuyts · 2021-12-01T14:48:29Z

I am not certain the currently implemented signature of try_from_fn is the right one. The most similar thing to this currently in the standard library is https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.try_for_each [...]

Seconding this. I'm trying to collect an iterator into an array, for which I'd like to write:

fn parse() -> Option<()> {
    let arr = array::try_from_fn(|_| self.iter.next())?;
    // ...
}

But because try_from_fn is hard-coded to return a Result, this does not work. Having an R: Try bound would solve this issue.

scottmcm · 2021-12-01T17:32:24Z

@yoshuawuyts I think my PR handles that scenario: https://github.com/rust-lang/rust/pull/91286/files#diff-534d866e6adad8a1f7577c2f1b3eed0b05d5f001c0d5032ac226393736940381R78-R82

scottmcm · 2021-12-03T22:09:15Z

I hate to re-bikeshed, but I stumbled on a possibility which I didn't see mentioned in #75644

I'm making a PR for array::repeat, to handle simple things like @leonardo-m's repeat(vec![]). But in doing that I noticed that there's not only iter::repeat -- which I was copying for array::repeat -- but there's also iter::repeat_with.

So I went to make array::repeat_with, but of course it's essentially identical to this tracking issue's array::from_fn. It's a much better parallel than iter::from_fn, as iter::repeat_with returns an "infinite" iterator and thus the closure is just -> Item (not from_fn's -> Option<Item>), like how the closure for creating an array is -> Element.

So a potential new coat of paint for the constructors could be

array::repeat for creating by cloning, like repeat(vec![1]).
array::repeat_with for creating by calling a closure, like repeat_with(|| Vec::with_capacity(10)).
array::try_repeat_with for creating by a fallible closure.

I don't know if this makes me feel differently about the usize argument. Allowing repeat_with(VecDeque::new) does feel somewhat more expected to me than from_fn(VecDeque::new), but I also still agree with the arguments in my previous comment. Of course, having both is also a possibility -- just like there's both iter::from_fn and iter::repeat_with, despite them being rather similar. Perhaps for nightly it would be reasonable to have both, with notes on their tracking issues to think about the other one if considering for stabilization?

c410-f3r · 2021-12-04T11:16:37Z

The two most important things about these functions are (1) Provide an unified way for creating custom arrays (it is common enough for std) and (2) Take off the user burden of having to deal with unsafe.

That said, I will personally support any proposal that will move any function or method towards stabilization as soon as possible. So if desired feel free to create repeat-like variants, maintain both versions or even close this issue.

Although some recent development is happening in this field, sometimes I think that custom array constructors will take, if ever, as long as try_reserve or more.

elichai · 2022-02-10T14:44:32Z

Since I've seen this, I've written [(); N].map(|_| ...) dozens of times, some required the int and some didn't.
So I'd love to see this stabilized :)

…ttmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here, tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn<T, const N: usize, F>(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17, implementation was [proposed](rust-lang#75644). * On 2021-09-29, tracking issue was [created](rust-lang#89379). * On 2021-10-09, the proposed implementation was [merged](bc8ad24). * On 2021-12-03, the return type of `try_from_fn` was [changed](rust-lang#91286 (comment)). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality, they are an attempt to move things forward, anything really. cc rust-lang#89379

yoshuawuyts · 2022-07-05T17:08:55Z

Now that #94119 has been merged to stabilize this, can we close this issue?

andylizi · 2022-07-05T17:11:26Z

Now that #94119 has been merged to stabilize this, can we close this issue?

Only from_fn is stabilized, try_from_fn is still unstable. The latter is blocked on #84277.

safinaskar · 2022-07-17T20:03:00Z

Please, also add this functions:

fn concat_arrs<T, const N: usize, const M: usize>(a: &mut ([T; N], [T; M])) -> &mut [T; N + M]; // Without coping, same for 3-tuples, 4-tuples, etc
fn concat_arr_of_arrs<T, const N: usize, const M: usize>(a: &mut [[T; N]; M]) -> &mut [T; N * M];

MatrixDev · 2022-07-18T08:15:37Z

Please, also add this functions:

fn concat_arrs<T, const N: usize, const M: usize>(a: &mut ([T; N], [T; M])) -> &mut [T; N + M]; // Without coping, same for 3-tuples, 4-tuples, etc
fn concat_arr_of_arrs<T, const N: usize, const M: usize>(a: &mut [[T; N]; M]) -> &mut [T; N * M];

Can't you just use std::mem::transmute for this? If you can do something without copying - it should be easy to just transmute it.
IMHO problem with from_fn is that it is much harder to replicate that functionality and also it is a very widely used pattern.

i509VCB · 2022-08-11T21:04:27Z

I was wondering if these functions could be const in the future when the pending issues with const fn are dealt with.

These functions actually seem pretty useful for lookup tables.

The new signature would probably be something like:

const fn from_fn<F, T, const N: usize>(cb: F) -> [T; N]
where
    F: ~const + FnMut(usize) -> T;

`enum-iterator` is a dependency for `vergen`, but because `v1.2.0` is causing the `error[E0658]`, we are restricting its version by defining it as `~1.1.3` here. To give more context, until we've added tracing, vergen v1.1.3 had been chosen by cargo. With tracing, if we use any version for vergen equal or greater than v7.0.0, cargo jumps enum-iterator from v0.8.1 to v1.2.0, which will cause an error when building in the CI: error[E0658]: use of unstable library feature 'array_from_fn' --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/enum-iterator-1.2.0/src/lib.rs:554:18 | 554 | Some(core::array::from_fn(|_| unreachable!())) | ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #89379 <rust-lang/rust#89379> for more information By adding `enum-iterator = "~1.1.3"`, we are giving v1.1.3 preference over the latest version (v1.2.0), so the build is fixed.

enum-iterator 1.2.0 is using unstable features, causing projects using vergen to fail when building: ``` error[E0658]: use of unstable library feature 'array_from_fn' --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/enum-iterator-1.2.0/src/lib.rs:554:18 | 554 | Some(core::array::from_fn(|_| unreachable!())) | ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #89379 <rust-lang/rust#89379> for more information ```

`enum-iterator` is a dependency for `vergen`, but because `v1.2.0` is causing the `error[E0658]`, we are restricting its version by defining it as `~1.1.3` here. To give more context, until we've added tracing, vergen v1.1.3 had been chosen by cargo. With tracing, if we use any version for vergen equal or greater than v7.0.0, cargo jumps enum-iterator from v0.8.1 to v1.2.0, which will cause an error when building in the CI: error[E0658]: use of unstable library feature 'array_from_fn' --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/enum-iterator-1.2.0/src/lib.rs:554:18 | 554 | Some(core::array::from_fn(|_| unreachable!())) | ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #89379 <rust-lang/rust#89379> for more information By adding `enum-iterator = "~1.1.3"`, we are giving v1.1.3 preference over the latest version (v1.2.0), so the build is fixed.

* Prevent E0658 by limiting enum-iterator version. enum-iterator 1.2.0 is using unstable features, causing projects using vergen to fail when building: ``` error[E0658]: use of unstable library feature 'array_from_fn' --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/enum-iterator-1.2.0/src/lib.rs:554:18 | 554 | Some(core::array::from_fn(|_| unreachable!())) | ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #89379 <rust-lang/rust#89379> for more information ``` * allow for 'variant_size_differences' Co-authored-by: Jason Ozias <jason.g.ozias@gmail.com>

Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here, tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn<T, const N: usize, F>(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17, implementation was [proposed](rust-lang/rust#75644). * On 2021-09-29, tracking issue was [created](rust-lang/rust#89379). * On 2021-10-09, the proposed implementation was [merged](rust-lang-ci/rust@bc8ad24). * On 2021-12-03, the return type of `try_from_fn` was [changed](rust-lang/rust#91286 (comment)). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality, they are an attempt to move things forward, anything really. cc rust-lang/rust#89379

stephaneyfx/enum-iterator@1.1.1...1.2.0

dead-claudia · 2023-02-07T04:08:46Z

Filed #89379 to try to get some extra traction on making the already-stabilized std::array::from_fn itself const.

c410-f3r · 2023-02-07T11:53:41Z

As @scottmcm said, it is necessary to have stable constant closures in order to "constify" array::from_fn in stable toolchains, which is probably going to happen in the next few years or so. See #106003.

I think it is already possible to at least "constify" the hidden underlying machinery but I am not totally sure.

rdrpenguin04 · 2023-05-28T21:38:06Z

Is there any reason this isn't stable yet?

NathanRoyer · 2023-07-20T09:42:40Z

Hello,

let mut parts = "Mary   had a small lamp".split_ascii_whitespace();
let parts: [&str; 5] = from_fn(|_i| parts.next().unwrap());
// produces: ["Mary", "had", "a", "small", "lamp"]

This works, but the documentation doesn't state that the callback parameter will grow upwards, so I'm not confident to use this code.
One day this could end up producing ["lamp", "small", "a", "had", "Mary"], if the implementation decided to "push" values from right to left, with a cb param going from 4 to zero; nothing says otherwise in the doc.

Is it possible that one day, we need the callback parameter to go in decreasing order?
If not, I think it would be nice to add a word about this in the documentation.

rdrpenguin04 · 2024-05-25T21:10:48Z

Are there any open questions about this? If not, could someone start an FCP?

c410-f3r · 2024-05-25T21:21:13Z

try_trait_v2 needs to be stabilized first and that probably won't happen in the near future. I am personally betting in 4 years or more (if ever).

rdrpenguin04 · 2024-05-26T15:33:16Z

Why does this depend on try trait necessarily? try_for_each is already in the standard library.

c410-f3r · 2024-05-26T16:57:03Z

Why does this depend on try trait necessarily?

Well, the original function returned Result but you can see more context about the use of Try in #90505, #91286 and
#94119 (comment).

try_for_each is already in the standard library.

EDIT: Oh I think it is because of concerns around the Residual associated type and try_for_each doesn't use that.

scottmcm · 2024-05-27T21:12:26Z

@c410-f3r is right -- the distinction is the use of the Residual mechanism, which has no stable use in the library yet

See #94119 (comment) and #94119 (comment)

Same questions as, for example, Iterator::try_find (#63178).

c410-f3r added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Sep 29, 2021

workingjubilee added the A-array Area: `[T; N]` label Oct 6, 2021

jplatte mentioned this issue Oct 11, 2021

Add 'core::array::from_fn' and 'core::array::try_from_fn' #75644

Merged

c410-f3r mentioned this issue Nov 2, 2021

Change array_from_fn signatures #90505

Closed

This was referenced Nov 5, 2021

Add read/write implems for generic arrays sharksforarms/deku#235

Merged

Remove use of unsafe in favor of 'core::array::from_fn' or 'core::array::try_from_fn' sharksforarms/deku#237

Open

scottmcm mentioned this issue Nov 27, 2021

Tracking Issue for ops::Residual (feature try_trait_v2_residual) #91285

Open

3 tasks

This was referenced Dec 7, 2021

Tracking Issue for core::array::(try_)repeat(_with) (feature array_repeat) #91613

Closed

Add resize(_with) and (try_)repeat(_with) for arrays #91506

Closed

Pratyush mentioned this issue Jan 5, 2022

Add array serialization impls arkworks-rs/algebra#371

Merged

6 tasks

c410-f3r mentioned this issue Feb 18, 2022

Stabilize array_from_fn #94119

Merged

jonasbb mentioned this issue Jul 26, 2022

Use the Iterator → Array function from the Rust standard library jonasbb/serde_with#292

Closed

c410-f3r changed the title ~~Tracking Issue for array_from_fn~~ Tracking issue for array_from_fn and try_array_from_fn Aug 19, 2022

joaoantoniocardoso mentioned this issue Aug 30, 2022

Fix cargo build error[E0658] mavlink/mavlink-camera-manager#124

Merged

Lost-Temple mentioned this issue Sep 21, 2022

documentation installation does not work bytecodealliance/wasm-tools#754

Closed

ghost mentioned this issue Nov 7, 2022

Use a GAT for Residual #104128

Closed

coding-by-sea referenced this issue in exercism/rust Nov 13, 2022

resistor-color: Use enum-iterator 1.2.0, up from 1.1.1

bd89c52

stephaneyfx/enum-iterator@1.1.1...1.2.0

dead-claudia mentioned this issue Feb 7, 2023

Make std::array::from_fn a const fn rust-lang/libs-team#178

Closed

jonasbb mentioned this issue Mar 4, 2023

Wishlist: Blocked on upstream changes jonasbb/serde_with#564

Open

camshaft mentioned this issue Mar 30, 2023

Use try_from_fn for array generator implementation once stable camshaft/bolero#133

Open

KKQanT mentioned this issue Jun 1, 2023

could not update anchor cli version 0.27.0 due to compiling enum-iterator-1.4.0 error coral-xyz/anchor#2507

Closed

c410-f3r mentioned this issue Sep 6, 2023

Tracking issue for cfg_match #115585

Open

3 tasks

not-fl3 mentioned this issue Sep 10, 2023

array de bin leak not-fl3/nanoserde#80

Merged

c410-f3r changed the title ~~Tracking issue for array_from_fn and try_array_from_fn~~ Tracking issue for try_array_from_fn May 25, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for `try_array_from_fn` #89379

Tracking issue for `try_array_from_fn` #89379

c410-f3r commented Sep 29, 2021 •

edited

Loading

dtolnay commented Nov 2, 2021

scottmcm commented Nov 27, 2021 •

edited

Loading

scottmcm commented Nov 28, 2021

yoshuawuyts commented Dec 1, 2021

scottmcm commented Dec 1, 2021

scottmcm commented Dec 3, 2021

c410-f3r commented Dec 4, 2021 •

edited

Loading

elichai commented Feb 10, 2022

yoshuawuyts commented Jul 5, 2022

andylizi commented Jul 5, 2022 •

edited

Loading

safinaskar commented Jul 17, 2022

MatrixDev commented Jul 18, 2022 •

edited

Loading

i509VCB commented Aug 11, 2022 •

edited

Loading

dead-claudia commented Feb 7, 2023

c410-f3r commented Feb 7, 2023

rdrpenguin04 commented May 28, 2023

NathanRoyer commented Jul 20, 2023

rdrpenguin04 commented May 25, 2024

c410-f3r commented May 25, 2024 •

edited

Loading

rdrpenguin04 commented May 26, 2024

c410-f3r commented May 26, 2024 •

edited

Loading

scottmcm commented May 27, 2024

Tracking issue for try_array_from_fn #89379

Tracking issue for try_array_from_fn #89379

Comments

c410-f3r commented Sep 29, 2021 • edited Loading

Public API

Steps / History

Unresolved Questions

dtolnay commented Nov 2, 2021

scottmcm commented Nov 27, 2021 • edited Loading

scottmcm commented Nov 28, 2021

yoshuawuyts commented Dec 1, 2021

scottmcm commented Dec 1, 2021

scottmcm commented Dec 3, 2021

c410-f3r commented Dec 4, 2021 • edited Loading

elichai commented Feb 10, 2022

yoshuawuyts commented Jul 5, 2022

andylizi commented Jul 5, 2022 • edited Loading

safinaskar commented Jul 17, 2022

MatrixDev commented Jul 18, 2022 • edited Loading

i509VCB commented Aug 11, 2022 • edited Loading

dead-claudia commented Feb 7, 2023

c410-f3r commented Feb 7, 2023

rdrpenguin04 commented May 28, 2023

NathanRoyer commented Jul 20, 2023

rdrpenguin04 commented May 25, 2024

c410-f3r commented May 25, 2024 • edited Loading

rdrpenguin04 commented May 26, 2024

c410-f3r commented May 26, 2024 • edited Loading

scottmcm commented May 27, 2024

Tracking issue for `try_array_from_fn` #89379

Tracking issue for `try_array_from_fn` #89379

c410-f3r commented Sep 29, 2021 •

edited

Loading

scottmcm commented Nov 27, 2021 •

edited

Loading

c410-f3r commented Dec 4, 2021 •

edited

Loading

andylizi commented Jul 5, 2022 •

edited

Loading

MatrixDev commented Jul 18, 2022 •

edited

Loading

i509VCB commented Aug 11, 2022 •

edited

Loading

c410-f3r commented May 25, 2024 •

edited

Loading

c410-f3r commented May 26, 2024 •

edited

Loading