Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

impl Display for Path #63822

Closed
benw opened this issue Aug 22, 2019 · 6 comments
Closed

impl Display for Path #63822

benw opened this issue Aug 22, 2019 · 6 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@benw
Copy link

benw commented Aug 22, 2019

It's deliberate that to date Path does not impl Display. It's a conservative stance that says that because the conversion to utf8 can be lossy, there isn't necessarily one obviously correct way to display a path.

I'd like to revisit that decision, in the interests of convenience. I can't imagine that anyone does anything other than call .display() or .to_string_lossy(). The current inconvenience might tend to encourage people to use &str/String rather than &Path/Pathbuf, which I think is a worse outcome. Also, impl Display for Path does not preclude anyone from providing a different way of displaying paths should they choose to.

@benw
Copy link
Author

benw commented Aug 22, 2019

Also I'd be interested to hear whether @huonw's thoughts on this have changed since #15827.

@Mark-Simulacrum
Copy link
Member

See most recent discussion in #49868 -- nominating for T-libs but I suspect that they may (still) not have sufficient bandwidth to deal with this question.

@Mark-Simulacrum Mark-Simulacrum added I-nominated T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Aug 22, 2019
@benw
Copy link
Author

benw commented Aug 22, 2019

Ah thanks, I searched but failed to find that.

@benw
Copy link
Author

benw commented Aug 22, 2019

Fwiw, after reading #49868 I am personally firmly in the camp of "Display means pretty-printing for user-visible output". I never understood Display to imply that roundtrip would be possible, and it's not obvious to me that "faithful representation" implies roundtrip.

However, I see that people with insight and experience have invested considerable effort in thinking and discussing this issue, it's certainly not trivial, and I'm glad to see that I'm not the only one thinking this is a pain point worth addressing.

Also, please don't panic, that would be awful.

@abonander
Copy link
Contributor

abonander commented Aug 23, 2019

Whether or not it's specified in the API contracts, I think there's a widespread expectation that a Display impl for a type will produce the original value (or a value which is semantically identical) when the result is passed to a corresponding FromStr (in this case, on PathBuf). This expectation is mostly due, I think, to the blanket implementation of ToString which by name alone has implied reciprocity with FromStr.

I can't think of any existing types that go against this expectation. Maybe floats?

@alexcrichton
Copy link
Member

I don't think enough has changed since #49868 for us to reconsider this, so I'm going to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants