Tracking issue for array::try_map

[eopb]

Feature gate: #![feature(array_try_map)]

This is a tracking issue for

Public API

https://doc.rust-lang.org/nightly/std/primitive.array.html#method.try_map

impl<T, const N: usize> [T; N] {
    pub fn try_map<F, R>(
        self,
        f: F
    ) -> <<R as Try>::Residual as Residual<[<R as Try>::Output; N]>>::TryType
    where
        F: FnMut(T) -> R,
        R: Try,
        <R as Try>::Residual: Residual<[<R as Try>::Output; N]>;
}

Steps / History

• Implementation: array::try_map #79713 Make array::{try_from_fn, try_map} and Iterator::try_find generic over Try #91286
• Decide on just-Result, vs potentially supporting Option and other Try types Decide on generic-ness of functions like Iterator::try_find and array::try_map #85115
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[a-lafrance]

Not sure if this change is still active, but I've stumbled upon a use case where a broader version of this for iterators in general, rather than strictly for arrays, would be useful. Is that something worth considering?

I'm totally new to both Rust contributions & open source in general, so I'm not sure if the idea of a general try_map is worth considering/pursuing, but I just thought I'd throw the idea out there since I thought it would be useful. Appreciate any feedback & insights!

(And, if it gets to that point, I'd be interested in taking a stab at implementing it. Would love to make a contribution to Rust, no matter how small!)

[scottmcm]

@arthurlafrance It'd suggest starting a conversation on IRLO about it. Or you can send a PR if it'd be easier to just write the code.

This change is still open, but is for tracking this specific change, not a good place to discuss an additional possible API.

[marcospb19]

+1 for this one, it's the only way I found to run a fallible .map() without collecting to a Vec, and still use Try afterward, which leads to a concise and straightforward code.

---

Not sure if this change is still active, but I've stumbled upon a use case where a broader version of this for iterators in general, rather than strictly for arrays, would be useful.

I guess that's what iter.collect::<Result<_>>() and the unstable iter.try_collect() are intended for.

[SmnTin]

Is there anything blocking stabilization?

[scottmcm]

Note that this, like array::try_from_fn and Iterator::try_find and similar, depends on the Residual trait mechanism for mapping from Foo<A> to Foo<[A; N]>, which is not used in any stable functions right now, so stabilization here is a bigger question than just the specific function in question.

See #94119 (comment) where array::from_fn was accepted but array::try_from_fn wasn't accepted due to this.

[tarcieri]

I believe #91285 is the tracking issue for stabilizing Residual

[scottmcm]

Right, stabilizing try_map doesn't require stabilizing Residual itself, but it does expose it, which is itself a commitment to have something like it forever.

[SmnTin]

Thank you for the replies! As far as I understood, there is a consensus that exposing Try trait in stable APIs is ok (e.g. Iterator::try_fold is stable) while exposing Residual is not, even though they both belong to try_trait_v2.

[SmnTin]

In this case, is it possible to rewrite the current implementation to only use Result/Option, stabilize it and revert back to a more general case when Residual trait gets stabilized?

[eopb]

I don't think it's possible to rewrite with Result/Option without changing the number or meaning of try_maps generic parameters in a way that won't be backward compatible with the revert.