Add Display for HostAndPort #328
Conversation
src/host.rs
Outdated
| @@ -192,6 +192,15 @@ impl<'a> HostAndPort<&'a str> { | |||
| } | |||
| } | |||
|
|
|||
| impl<S: AsRef<str>> fmt::Display for HostAndPort<S> { | |||
| fn fmt(&self, f: &mut Formatter) -> fmt::Result { | |||
| try!(self.host.fmt(f)); | |||
There was a problem hiding this comment.
I wonder if there's an easy way to write this all at once so that we return an Err Result and don't write anything to the formatter, or we return Ok and the formatter has the full thing? I don't think Display makes that guarantee, but it seems like a "nice to have".
There was a problem hiding this comment.
@SamWhited I don’t understand what you’re proposing. Could you explain some more or give an example?
In any case, it is incorrect for a Display::fmt impl to return Err other than for propagating errors that ultimately come from the Formatter. Formatting is supposed to be infallible, it’s only writing to the output stream (for example to a file on a full disk) that can fail.
There was a problem hiding this comment.
Yes, sorry, on rereading that was confusing.
I'm suggesting that if possible we do a single, atomic, write to the formatter. Right now we might write host: and then something bad happens and writing the port fails so we end up with a half written thing.
It's probably not actually an issue.
There was a problem hiding this comment.
Display impls are pretty much never "atomic" in that sense. On the contrary, they are designed to be composable like this. The only way I can think of to make on "atomic" would be to first format to a String and then write that, but that would add unnecessary costly memory allocations. A large number of them, for deeply nested Display::fmt calls.
There was a problem hiding this comment.
ooh yah, an allocation would be worse. LGTM then.
src/host.rs
Outdated
| @@ -192,6 +192,15 @@ impl<'a> HostAndPort<&'a str> { | |||
| } | |||
| } | |||
|
|
|||
| impl<S: AsRef<str>> fmt::Display for HostAndPort<S> { | |||
| fn fmt(&self, f: &mut Formatter) -> fmt::Result { | |||
| try!(self.host.fmt(f)); | |||
There was a problem hiding this comment.
what about using the "new" ? operator?
self.host.fmt(f)?;
self.write_str(":")?;
self.port.fmt(f)
There was a problem hiding this comment.
I was about to suggest that as a nit pick :) please do (IMO)! It doesn't affect the other thing being discussed, but it is probably worth doing either way
There was a problem hiding this comment.
Let’s do this separately, on the whole repo: #330
There was a problem hiding this comment.
Since #331 has landed first, please switch to ?. Thanks!
tests/unit.rs
Outdated
| ) | ||
| ]; | ||
|
|
||
| for &(ref input, result) in &data { |
There was a problem hiding this comment.
Avoid for loops like this for unit tests. When a test fail it will show the line number for assert_eq!, but that doesn’t show which of the entries failed.
In this case I think duplicating the assert_eq! + format! line is fine, since it’s not long and there’s only two test cases. In a case when de-duplicating testing code is desirable, consider using a macro like assert_from_file_path! in this file. This makes panic messages use the line number of the macro usage.
|
I addressed your comments, and added the |
|
Oops, I noticed, that |
|
Review status: 0 of 2 files reviewed at latest revision, 2 unresolved discussions. Comments from Reviewable |
|
Reviewed 1 of 2 files at r2, 1 of 1 files at r3. Comments from Reviewable |
|
Looks good. @bors-servo r+ |
|
📌 Commit a6421f6 has been approved by |
Add Display for HostAndPort Fix #300 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/rust-url/328) <!-- Reviewable:end -->
|
☀️ Test successful - status-travis |
Fix #300
This change is