Implement tuple<->array convertions via From

[WaffleLapkin]

This PR adds the following impls that convert between homogeneous tuples and arrays of the corresponding lengths:

impl<T> From<[T; 1]> for (T,) { ... }
impl<T> From<[T; 2]> for (T, T) { ... }
/* ... */
impl<T> From<[T; 12]> for (T, T, T, T, T, T, T, T, T, T, T, T) { ... }

impl<T> From<(T,)> for [T; 1] { ... }
impl<T> From<(T, T)> for [T; 2] { ... }
/* ... */
impl<T> From<(T, T, T, T, T, T, T, T, T, T, T, T)> for [T; 12] { ... }

IMO these are quite uncontroversial but note that they are, just like any other trait impls, insta-stable.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @Mark-Simulacrum

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

[WaffleLapkin]

r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs

[WaffleLapkin]

@rustbot label -S-waiting-on-review +S-waiting-on-author

[WaffleLapkin]

I've removed () <-> [] impls because they break inference in the following tests:

• ui/hygiene/hir-res-hygiene.rs
• ui/suggestions/type-ascription-instead-of-path-2.rs
• ui/issues/issue-32709.rs

They all basically do the following:

fn f() -> Result<(), ()> {
    Ok(())?; // <--
    Ok(())
}

For this to work you need to infer ?T in Result<(), ?T> having only (): From<?T>. Currently this works because the only impl From for () is the identity impl, so rustc picks it up and infers ?T = ().

IIRC this is not considered a breaking change per rust rules, because it can be fixed by adding types:

fn f() -> Result<(), ()> {
    Ok::<_, ()>(())?; 
    //^^^^^^^^^
    Ok(())
}

However I'm not sure how widespread this pattern is and if this is worth the potential breakage.

[WaffleLapkin]

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #98807) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[camelid]

ping from triage: What's the status of this PR?

[scottmcm]

Looks like this is old enough that it pre-dates ACPs, so I'll nominate it for libs-api to say what they want.

[WaffleLapkin]

@camelid pretty much what the tags say: this is waiting on a T-libs-api decision

[m-ou-se]

We briefly discussed this in the libs-api meeting, and we were wondering if there are any motivating use cases.

[CryZe]

From the top of my head I can't really recall too many specific examples, but I definitely needed this a couple of times. In particular when dealing with different crates where one crate returns colors as (r, g, b, a) but another wants [r, g, b, a]. Similarly for xyz coordinates. Older APIs usually used tuples a lot (including std) because arrays were a lot less powerful (in terms of destructuring for example), but nowadays arrays should be preferred, so you often want to convert.

[scottmcm]

Any thoughts on how often it's needed as From (or more likely .into(), I guess) vs when a method would be fine?

Having .into_tuple() and .into_array() methods would be able to go in unstable, wouldn't have the () <-> [] breakage, and would have the bonus that you'd never need to write something like <(_, _, _, _, _, _)>::from(array) because array.into_tuple() would know the output type, but would of course have the downside of not working with .into().

[WaffleLapkin]

So, I couldn't find the exact use case which caused this PR, going through the chat logs of the time I saw this:

the trait `std::convert::From<(usize, usize)>` is not implemented for `[_; 2]`

But I'm not sure what caused this / what was the context.

I would think that the use-case was similar to what @CryZe described — using multiple APIs some of which prefer tuples and some of which prefer arrays.

---

@scottmcm I think that using From here is valuable here, since it can be quite often seen on the API boundary. .into_tuple() and .into_array() would be fine too, although I would still prefer From (the () <-> [] as a method seems pointless to me, you are just better off writing it by hand, I think).

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se 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

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. 🔔

[joshtriplett]

When we discussed this in today's @rust-lang/libs-api meeting, we were happy to see it merged.

But also, we wanted to track down whatever issue is causing the spurious suggestions about From<T> as visible in the tests this updates. Note that this issue is not new to these new impls, and already existed with other spuriously suggested impls. Could someone please file an issue for that, or point to an existing one if it's already filed?

Also, separate from that, suggestions should be versionsorted (1, 2, 3), not alphabetically sorted (10, 11, 12, 1, 2, ...).