Stabilize array_from_fn

[c410-f3r]

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:

// 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.
• On 2021-09-29, tracking issue was created.
• On 2021-10-09, the proposed implementation was merged.
• On 2021-12-03, the return type of try_from_fn was changed.

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 #89379

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[lcnr]

i think we should change the generic arguments to

Suggested change

	pub fn from_fn<F, T, const N: usize>(mut cb: F) -> [T; N]
	pub fn from_fn<T, const N: usize, F>(mut cb: F) -> [T; N]

this makes it a lot more similar to other such functions with the function being last.

[scottmcm]

We might even consider going to

Suggested change

	pub fn from_fn<F, T, const N: usize>(mut cb: F) -> [T; N]
	pub fn from_fn<T, const N: usize>(mut cb: impl FnMut(usize) -> T) -> [T; N]

Because if the rules change to "you can turbofish the explicit generic parameters but not the APITs", then that would be nicer -- from_fn::<i32, N>(...) instead of ::<i32, N, _>.

That would, of course, mean that they'd need to be provided by context in the mean time, however. But TBH I prefer that anyway, as I find from_fn::<_, 4, _> distasteful. (The closure almost always provides the T.)

[scottmcm]

Note for libs-api: This would be the first stable usage of the https://doc.rust-lang.org/nightly/std/ops/trait.Residual.html mechanism (the other things like Iterator::try_find are still unstable) so it probably deserves extra careful consideration.

[scottmcm]

It is being assumed that indices are useful and shouldn't be removed from the callbacks

To hopefully help team discussion, I'll link my rationale in favour of usize -> T: #89379 (comment)

array::repeat_with might also be good (#89379 (comment)), but that doesn't need to keep us from stabilizing the takes-usize version. We can always have two constructor functions later if we want -- after all, we also have iter::from_fn and iter::repeat_with even though iter::repeat_with(|| f()) can always be written as iter::from_fn(|| Some(f())).

[joshtriplett]

We discussed this in today's libs-api meeting. Out of an abundance of caution, since this needs the Try trait and the residual mechanism, we decided to not stabilize try_from_fn for now; we'd like to just stabilize from_fn first and defer try_from_fn until try is stabilized.

Separately from that, we'd like to see the arguments reordered to put the function type last, which will allow us to in the future omit that argument (with further language enhancements).

[c410-f3r]

The fact that R implements Try shouldn't be a problem because Iterator::try_for_each, Iterator::try_fold, and DoubleEndedIterator::try_rfold already return R: Try. Here also goes a list with a fraction of unstable things used in stable stuff:

• Pattern (https://doc.rust-lang.org/std/str/pattern/trait.Pattern.html) in stable method parameters
• TrustedLen (https://doc.rust-lang.org/std/iter/trait.TrustedLen.html) in stable structure bounds
• Allocator (https://doc.rust-lang.org/std/alloc/trait.Allocator.html) across several stable data structures

Result<[T; N], E>, which was the original return, could also de used instead of R: Try. FWICT, Try is a superset of Result so I guess it is probably possible to replace an initial Result<[T; N], E> with a future R: Try.

With all that said, I ask the responsible party to reconsider the stabilization of try_from_fn with any desired return type. As previously stated, there are no ways to create fallible arrays without recurring to unsafe, boilerplate or external dependencies.

[joshtriplett]

The fact that R implements Try shouldn't be a problem because Iterator::try_for_each, Iterator::try_fold, and DoubleEndedIterator::try_rfold already return R: Try

That's a compelling argument, to me.

[cuviper]

The fact that R implements Try shouldn't be a problem because Iterator::try_for_each, Iterator::try_fold, and DoubleEndedIterator::try_rfold already return R: Try.

Those stable examples don't use the Residual mapping though, which gives a sort of type-constructor conversion from R: Try to a related TryType. It's more like Iterator::try_collect, try_find, and try_reduce, which are all still unstable. Once we stabilize array::try_from_fn or any of those others, we're locked into needing that mechanism in Try.

(This was noted before in #94119 (comment))

[c410-f3r]

The fact that R implements Try shouldn't be a problem because Iterator::try_for_each, Iterator::try_fold, and DoubleEndedIterator::try_rfold already return R: Try.

Those stable examples don't use the Residual mapping though, which gives a sort of type-constructor conversion from R: Try to a related TryType. It's more like Iterator::try_collect, try_find, and try_reduce, which are all still unstable. Once we stabilize array::try_from_fn or any of those others, we're locked into needing that mechanism in Try.

(This was noted before in https://github.com/rust-lang/rust/pull/94119/files#r815334585)

The fact that Try is a nightly feature shouldn't lock any possible compromise but it seems that such acceptance could imply more future pseudo-"breakage".

Regardless, you indeed got a point so I withdraw my request for reconsidering try_from_fn. Thank you for all the participants.

@joshtriplett The PR will be updated according to #94119 (comment)

[joshtriplett]

@cuviper Thanks for catching that distinction.

[c410-f3r]

The order of the type parameters was modified and the feature of try_from_fn was renamed to array_try_from_fn

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

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]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

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.

[c410-f3r]

Someone has to r+

[scottmcm]

Thanks! The updated generic order update is in, and the version matches the current one (after the bump last week).

@bors r+

[bors]

📌 Commit d917112 has been approved by scottmcm

[c410-f3r]

Thanks! The updated generic order update is in, and the version matches the current one (after the bump last week).

@bors r+

Thanks @scottmcm

[bors]

⌛ Testing commit d917112 with merge 09ea213...

[bors]

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 09ea213 to master...

[rust-timer]

Finished benchmarking commit (09ea213): comparison url.

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

• Primary benchmarks: 😿 relevant regression found
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	1	1	0	2	1
mean2	4.0%	1.4%	N/A	-2.2%	4.0%
max	4.0%	1.4%	N/A	-2.6%	4.0%

Cycles

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: 😿 relevant regressions found

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	1	2	1	0	2
mean2	2.2%	3.1%	-2.4%	N/A	-0.1%
max	2.2%	3.5%	-2.4%	N/A	-2.4%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. number of relevant changes ↩ ↩²

2. the arithmetic mean of the percent change ↩ ↩²