-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Stabilize std::path #23229
Stabilize std::path #23229
Conversation
Note: this needs to be rebased and complete testing on Windows, but it otherwise ready for review. |
@@ -1324,11 +1368,14 @@ impl cmp::Ord for Path { | |||
} | |||
|
|||
/// Freely convertible to a `Path`. | |||
#[stable(feature = "rust1", since = "1.0.0")] | |||
pub trait AsPath { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this hold off on being stable while generic conversion traits are landing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My impression was that this was one of the motivating reasons for generic conversion traits, so yeah we probably want to wait for that.
A few nits here and there, otherwise r=me |
Comments addressed. Will send to bors once it passes tests locally. |
b91a0bb
to
4082f1c
Compare
cc #23283, a case where the semantics of |
32ee399
to
92475b8
Compare
This commit stabilizes essentially all of the new `std::path` API. The API itself is changed in a couple of ways (which brings it in closer alignment with the RFC): * `.` components are now normalized away, unless they appear at the start of a path. This in turn effects the semantics of e.g. asking for the file name of `foo/` or `foo/.`, both of which yield `Some("foo")` now. This semantics is what the original RFC specified, and is also desirable given early experience rolling out the new API. * The `parent` function now succeeds if, and only if, the path has at least one non-root/prefix component. This change affects `pop` as well. * The `Prefix` component now involves a separate `PrefixComponent` struct, to better allow for keeping both parsed and unparsed prefix data. In addition, the `old_path` module is now deprecated. Closes rust-lang#23264 [breaking-change]
This commit stabilizes essentially all of the new `std::path` API. The API itself is changed in a couple of ways (which brings it in closer alignment with the RFC): * `.` components are now normalized away, unless they appear at the start of a path. This in turn effects the semantics of e.g. asking for the file name of `foo/` or `foo/.`, both of which yield `Some("foo")` now. This semantics is what the original RFC specified, and is also desirable given early experience rolling out the new API. * The `parent` method is now `without_file` and succeeds if, and only if, `file_name` is `Some(_)`. That means, in particular, that it fails for a path like `foo/../`. This change affects `pop` as well. In addition, the `old_path` module is now deprecated. [breaking-change] r? @alexcrichton
This commit stabilizes essentially all of the new
std::path
API. TheAPI itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
.
components are now normalized away, unless they appear at thestart of a path. This in turn effects the semantics of e.g. asking for
the file name of
foo/
orfoo/.
, both of which yieldSome("foo")
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
parent
method is nowwithout_file
and succeeds if, and onlyif,
file_name
isSome(_)
. That means, in particular, that it failsfor a path like
foo/../
. This change affectspop
as well.In addition, the
old_path
module is now deprecated.[breaking-change]
r? @alexcrichton