Change array_from_fn signatures

[c410-f3r]

Superseded by #91286

Implementation

These functions are using the same inner code of other array methods and such feature already ensures a reliable execution.

Signature

Originally, indices returned by the callback were introduced as auxiliary parameters since arrays are hereditary indexed and known at compile-time.

• https://github.com/PyO3/pyo3/blob/fc90092ef9090e034ff05323348da21d486735fa/src/conversions/array.rs#L63
• https://github.com/c410-f3r/ndsparse/blob/7c6803109aa1a8c68dcdb95c498c60feca011ca7/ndsparse/src/csl/csl_utils.rs#L84
• https://github.com/PistonDevelopers/hematite/blob/5e387561d7412b28f7b35977d35fa74b3cb1a677/src/minecraft/region.rs#L19
• https://github.com/LukasKalbertodt/lina/blob/3de7d87826528e17a03eb24ea690789e2535ac7a/src/vec/point.rs#L132

But due to #75644 (comment) and #75644 (comment), no index will be returned to avoid further concerns or discussions.

[rust-highfive]

r? @dtolnay

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

[c410-f3r]

@rustbot label +T-libs
r? @yaahc

[CryZe]

I've seen that nowadays try_ functions return R: core::ops::Try<Output = T> instead. I think try_from_fn should probably follow that. E.g. Iterator::try_for_each

[c410-f3r]

After a week without comments, I am assuming that using the Try trait is indeed the way to go.

[dtolnay]

I am not prepared to stabilize this instantly with the signature change. This needs to go into nightly with the new signature so that we can get a picture of whether this gives rise to inconvenient inference issues in practical use, or anything else that may come up.

[c410-f3r]

I am not prepared to stabilize this instantly with the signature change. This needs to go into nightly with the new signature so that we can get a picture of whether this gives rise to inconvenient inference issues in practical use, or anything else that may come up.

Sigh...

Done

[scottmcm]

whether this gives rise to inconvenient inference issues in practical use

The usual problem is that an inferred return type is not compatible with ?.

I copied over the function signature here into the playground https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=0cdced05401eea1621827f86537ccd18, and sure enough, inference failures:

error[E0284]: type annotations needed
  --> src/lib.rs:17:9
   |
17 |         try_from_fn(|| -> Result<i32, TryFromIntError> { i32::try_from(i) })?,
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
   |
   = note: cannot satisfy `<_ as Try>::Residual == _`

And, importantly, that's happening despite the explicitly-specified closure type and a fully available return type (no try blocks or IIFEs or similar to confuse it).

That ? usage, however, compiles fine with the current nightly try_from_fn: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b42ef33453354dce78f3299a1a40809a

It also compiles fine with the approach in #91286: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3bc991d03ff52c972fc4c3b6dd02c46e

(Sorry for not seeing this PR sooner.)

[c410-f3r]

The suddenly and surprising depreciation of this PR over #91286 was unexpected but I don't think anyone could do better than the very person who elaborated and implemented the new try infrastructure

Superseded by #91286

[scottmcm]

Thanks for continuing to push these forward, @c410-f3r -- they're critical building blocks and I'd love to see them in stable.