Implement From<[T; ..]> for (T, ..) and From<(T, ..)> for [T; ..]

[tomaka]

This adds:

impl<T> From<[T; 3]> for (T, T, T) { .. }
impl<T> From<(T, T, T)> for [T; 3] { .. }

And same for all other arrays and tuples dimensions, up to 32 elements for tuple->array and up to 12 elements for array->tuple (similar to the other trait implementations on arrays and tuples).

Note that the first one requires Clone, because otherwise I couldn't manage to make it compile. Fixed.

If the changes are good, this still needs some tests and an issue number.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[ollie27]

I think it makes sense to only implement this for tuples up to size 12 in both directions in order to keep it symmetrical.

[tomaka]

I also noticed that the order of the elements may be wrong.

Could I get some additional feedback on the nature of the changes? And if it's approved, I'll clean up the PR.

[retep998]

I think something like this would be very useful. Shame about that Clone requirement though.

[apasel422]

It's possible to implement this without the Clone bound using ptr::read and mem::forget.

EDIT: Another option is slice patterns (though they are unstable):

let [a, b, c] = [1, 2, 3];
(a, b, c)

[tomaka]

Another option is slice patterns (though they are unstable):

Doesn't work either: http://is.gd/Kmwznm

But yeah I could use ptr::read.

[arielb1]

@tomaka

Then go the ptr way.

[apasel422]

@tomaka This seems to work:

fn foo<T>([a, b, c]: [T; 3]) -> (T, T, T) {
    (a, b, c)
}

[bluss]

rustc has something related that I'd love to have. Could be AsRef impls. tuple_slice.rs

[tomaka]

@bluss That's really nice, but I guess that the problem is that the internal representation of tuples may change in the future.

Anyway, this PR should now be good to go except for the issue number.

[ollie27]

I still don't think tuple->array conversions should be implemented to tuples longer than 12 as nothing else is implemented for tuples that long.

[bluss]

@tomaka Right. Given the rustc trait, I was hoping we could solidify the repr.

[huonw]

Stability doesn't work for trait implementations, so these will be automatically stable if they land.

(Nominating for libs team discussion.)

[alexcrichton]

These'll be insta-stable unfortunately so could these be #[stable] instead of #[unstable]?

[alexcrichton]

I agree with @huonw that we'll likely want to chat about this in the libs triage. I'm personally a little wary about adding these sorts of impls as it seems there is no end to the various sorts of conversions that could be added.

[tomaka]

The motivation behind this change is that there is no consensus on whether a geometrical vector or geometrical point should be represented as [f32; 3] or (f32, f32, f32).
Sometimes the former is more practical, sometimes it's the latter.

[alexcrichton]

The libs team discussed this in triage yesterday and the conclusion was to close this for now. While we typically have these sorts of conversions for arrays it's normally done with the intention of replacing it with type-level generic integers one day. A feature such as this, however, would require a relationship between variadic generics, tuples, and type-level integers which is likely much farther out.

As a result we concluded that it should be fine to have small conversion functions in-crate for these now.