Add fmt::Show trait implementation to posix and windows Path's

[wickerwaka]

Implement the Show trait for both Path implementations.

[wickerwaka]

@vks not if I want to use #[deriving(Show)] on a struct that contains a Path. Doesn't it seem reasonable that Path would implement show? Its a pretty common thing people want to do.

[vks]

I meant: Couldn't your implementation of Show use display?
(Or does this prevent using #[deriving(Show)]?)

[sfackler]

cc @kballard

[wickerwaka]

@vks ah yes, good point

[aturon]

See the discussion thread here about some of the tradeoffs.

[lilyball]

This has been proposed multiple times before. It's always been considered too risky to have Path implement Show, because it's extremely common for people to assume file paths can be represented as strings, and therefore that producing a string from a Path will yield a value that accurately represents the path and can be used to re-create an identical Path object. However, this is not the case. This is why the .display() method exists, to make it really obvious that this is not an accurate representation.

The proper solution to #[deriving(Show)] is to provide the ability to customize the deriving. #14268 is related, though I believe there are other relevant issues as well.

[alexcrichton]

At this time the std::path module is still a candidate for stabilization, and this will likely come up during the stabilization process regardless. For now, though, using the display() method is in line with the current design of the module. In light of this, I'm going to close this out of inactivity for reconsideration when std::path comes up for stabilization.