Tuples should be fundamental

[SimonSapin]

Test case:

use std::net::{Ipv4Addr, Ipv6Addr, SocketAddr, ToSocketAddrs};
use std::{vec, io};

pub enum Host {
    Domain(String),
    Ipv4(Ipv4Addr),
    Ipv6(Ipv6Addr),
}

impl ToSocketAddrs for (Host, u16) {
    type Iter = vec::IntoIter<SocketAddr>;
    fn to_socket_addrs(&self) -> io::Result<Self::Iter> {
        unimplemented!()
    }
}

Output with rustc 1.8.0-nightly (fae5162 2016-02-13):

a.rs:10:1: 15:2 error: the impl does not reference any types defined in this crate; only traits defined in the current crate can be implemented for arbitrary types [E0117]
a.rs:10 impl ToSocketAddrs for (Host, u16) {
a.rs:11     type Iter = vec::IntoIter<SocketAddr>;
a.rs:12     fn to_socket_addrs(&self) -> io::Result<Self::Iter> {
a.rs:13         unimplemented!()
a.rs:14     }
a.rs:15 }
a.rs:10:1: 15:2 help: run `rustc --explain E0117` to see a detailed explanation
error: aborting due to previous error

But the impl does define a type defined in this crate, Host.

Is this impl fundamentally problematic, or could coherence rules be extended for tuples?

[arielb1]

That's the annoying future compatibility rules. Tuples are currently not #[fundamental] - I imagine that we should fix this. cc @nikomatsakis

[nikomatsakis]

Hmm. It does seem like tuples ought to be considered fundamental. I'd not be opposed to an RFC on this topic.

[SimonSapin]

In case that’s a hint for me to write an RFC: I don’t feel I can since I don’t understand the finer details of coherence rules or what fundamental means in this context, only the end result of “I can’t write this seemingly-reasonable code”.

[nikomatsakis]

It wasn't really a hint to YOU Simon ;)

Probably this doesn't merit a full RFC actually; an amendment to the existing one might suffice.

On Tue, Feb 16, 2016 at 09:07:54PM -0800, Simon Sapin wrote:

In case that’s a hint for me to write an RFC: I don’t feel I can since I don’t understand the finer details of coherence rules or what fundamental means in this context, only the end result of “I can’t write this seemingly-reasonable code”.

---

Reply to this email directly or view it on GitHub:
#31682 (comment)

[jashephe]

Are there any recommended work-arounds for this? I just ran into the same problem (entertainingly, with pretty must the exact code posted in the test case). Has there been any progress on an RFC addition?

[sharpjs]

I've also run into this issue. @jashephe My workaround was just to make my own tuple-like struct and implement the trait for that struct instead.

impl ToSocketAddrs for Pair<Host, u16> { ...

My quick search did not find any RFC for making tuples #[fundamental]. I'm not opposed to writing an RFC for this. I've been rusting since 1.0, but only learned about #[fundamental] a few minutes ago. I'd need to do a bit of research before attempting my first RFC.

[nikomatsakis]

I think treating tuples as fundamental makes sense. We should probably write up an RFC for it.

[sharpjs]

Well, then, I'll attempt to write it! I'm eager to make my first contribution (however small) to Rust.

[Mark-Simulacrum]

I'm told that @nikomatsakis is the person to speak to why tuples aren't fundamental. @arielb1 says that they aren't sure why this is the case.

[Mark-Simulacrum]

Nominating for lang team. I believe we should close this issue in favor of one on the rfcs repo, though it seems unlikely that unless someone motivated steps up to write the RFC it'll happen. Perhaps we could mentor someone? I recall @nrc had a mentoring repo for RFCs...

[Mark-Simulacrum]

Closing. If someone wants to pursue this, please follow the RFC process here https://github.com/rust-lang/rfcs#before-creating-an-rfc. There's no real point in the lang team discussing this until that happens.

[cramertj]

This is actually included as a part of my variadic generics RFC. It might be useful to break it out into a smaller proposal, though.