std::path::Path::Display allocates internally

[jethrogb]

It should be possible to display a Path without doing any additional allocations, by having the lossy conversion use Formatter directly.

[martinhath]

I would like to try this out 😄

[martinhath]

So I've done some digging. The allocation comes from path::Display::fmts self.path.to_string_lossy(), which eventually gets down to os_str::Slice::to_string_lossy, which calls String::from_utf8_lossy, yes? (and since String::from_utf8_lossy returns Cow<str>, the allocation is only done if the path contains invalid Unicode sequeces?)

However, I am a little confused by what you mean about "having the lossy conversion use Formatter directly" means. Do you suggest giving the Formatter the Path directly, and do the non-Unicode sequence conversion in the Formatter?

[jethrogb]

I think that's what I mean? You'll need to loop through the bytes and get valid chars. You can then write those chars using fmt::Write::write_char

[martinhath]

Some more questions:

• I found Tracking issue: UTF-8 decoder in libcore #33906 (with PRs add core::char::DecodeUtf8 #33907 and Yield Err in char::decode_utf8 per Unicode, like String::from_utf8_lossy #35947), which seems very relevant here. However, the issue is about UTF-8, while the docs for path::to_string_lossy()(which is what path::Display uses internally) only mentions "any non-Unicode sequences". Is this a significant difference?
• If char::decode_utf8 fits this issue it makes sense to wait for it to be stable, right? (I imagine using unstable features isn't something we'd like to do, unless we really need to)

Or is there some hidden thing I haven't seen yet?

[jethrogb]

The to_string_lossy documentation is specifically talking about non-unicode byte sequences in the “Unicode Transformation Format (8 bits)” (UTF-8). So yes, that module would be useful. And I think it's fine to use it in std internally.