-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
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. |
Ah thanks, I searched but failed to find that. |
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. |
Whether or not it's specified in the API contracts, I think there's a widespread expectation that a I can't think of any existing types that go against this expectation. Maybe floats? |
I don't think enough has changed since #49868 for us to reconsider this, so I'm going to close this. |
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.
The text was updated successfully, but these errors were encountered: