impl ToSocketAddrs for String

[lambda]

ToSocketAddrs is implemented for a number of different types,
including (IpAddr, u16), &str, and various others, for the
convenience of being able to run things like
TcpListener::bind("10.11.12.13:1415"). However, because this is a
generic parameter with a trait bound, if you have a String you cannot
pass it in, either directly as TcpListener::bind(string), or the
TcpListener::bind(&string) as you might expect due to deref coercion;
you have to use TcpListener::bind(&*string), which is noisy and hard
to discover (though #39029 suggests better error messages to make it
more discoverable).

Rather than making people stumble over this, just implement
ToSocketAddrs for String.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[brson]

Hm, this doesn't seem like a 'to' conversion, but an 'into' conversion. I'm trying to think if this would make it easy to accidentally write less efficient code, but I can't think how.

[alexcrichton]

Looks good to me, thanks! Impls like this are actually instantly stable so we just go ahead and tag them with a #[stable] rather than #[unstable]. Feel free to just pick a feature name out of thin air for that!

@rfcbot fcp merge

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, 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.

[alexcrichton]

@brson hm I'm not sure that there's any resources that the return value of ToSocketAddrs can share with String (e.g. some memory buffer). In general perf probably isn't too much of a worry here b/c you're doing a DNS lookup as well.

[lambda]

This is actually a "to" because it takes &self. It happens that if you use this as a generic argument like TcpListener::bind does, that will consume the string (as I demonstrate in the test cases), but I think that's generally OK, and it allows you to pass &string in as well if you don't want to consume it.

With this patch, any of the following should work (using TcpStream::connect as an example since it's a better example of when you may want to use this, if you get a hostname and port from different sources and need to build a string from them).

TcpStream::connect("hostname:42");  // Literal &str
TcpStream::connect(&*format!("{}:{}", host, port));  // String, the old way
TcpStream::connect(format!("{}:{}", host, port));  // String, the new way, consumes the string
let destination = format!("{}:{}", host, port);
TcpStream::connect(&destination);  // String, the new way, by reference, if you don't want to consume

I don't think there are any performance implications, just one way that you might consume the string by accident which you can fix by inserting a single & like you'd expect.

[lambda]

Also pushed new version with stability marked, as suggested by @alexcrichton.

[xen0n]

Hmm, this makes writing things like TcpStream::connect(format!("{host}:{port}")) much easier, which I'd rather not see happen, but given the other examples shown above we can't stop people from doing similarly wrong things either. I'm fine with the addition then.

[golddranks]

I found allowing passing of the ownership bad design at first. But then again, @alexcrichton had a good point about the DNS lookup dominating perf.

Besides, if you are using a String that you don't need an ownership of in the future, the odds are that you've built that string for that occasion, for passing that into a function, and just have no use for it afterwards.

If you have an use for it, unless you are a total newbie, you are going to prefer passing a reference over cloning it, and if you are a total newbie, that's not likely to be the most pressing problem in your code.

So, after all, the downsides don't seem too dire, and it's an ergonomics win.

[lambda]

It is possible to switch this to an impl on &String, but I feel that the ergonomics win is better for String so it works all of the ways you might try.

[tbu-]

I share @llogiq's concern:

I'm not keen on having that impl consuming the String. It will lead to more confusing errors down the line when trying to re-use the String.

Can we impl ToSocketAddrs for &String instead?

– llogiq on /r/rust

[golddranks]

Consuming String and trying to use it later will lead to "use of moved value" error, whereas passing String where &String is expected will lead to "the trait ... is not implemented for std::string::String" error. Both are quite helpful. (Where the move and later use happens is shown, and the fact that an implementation exists for &String is shown.)

Which is more confusing? After considering the the fact that format!({}:{}, addr, port) might be quite common in the argument position where ToSocketAddrs is expected, I'd be inclined to implement for String. Edit: is it? There's an implementation for (&'a str, u16)...

[tbu-]

In this case, you'd be better off passing (addr, port), e.g. ("github.com", 80) instead of format!("{}:{}", "github.com", 80).

[xen0n]

@tbu- this is more about helping Rust newcomers than pursuing elegance, as several others have pointed out.

[tbu-]

@xen0n I'm aware of that, and not opposed to adding a &String implpementation. Does it help if we promote slow solutions though? It'll lead to code like the format! above (where a universally faster solution exists) or like let s = String::from("github.com:80"); tcp.connect(s.clone()); where &s would be much more useful.

If we want such a change of string ideology, we should probably decide about that globally and not on a case-by-case basis, because it'll lead to an inconsistent standard library otherwise. E.g.: why does connect accept String, but I can't do a String + String? Would also be easier for newcomers.

[golddranks]

Comparison to String + String concatenation is a good point :)

[llogiq]

I personally feel that helpful suggestions from the compiler are going to be more useful in the long run than clogging up std with impls for everything and the kitchen sink.

[alexcrichton]

ping @BurntSushi, @brson, @sfackler (checkboxes)

[brson]

After looking at it again I don't have any particular concerns, and it seems like most comments on thread are either pro or meh, not a lot of total opposition.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[alexcrichton]

@bors: r+

[bors]

📌 Commit a5f2f36 has been approved by alexcrichton

[bors]

⌛ Testing commit a5f2f36 with merge 18b6b8f...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 18b6b8f to master...