Tracking issue for `try_array_from_fn`

[c410-f3r]

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.

[dtolnay]

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]

@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]

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]

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]

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

[scottmcm]

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]

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.