Repository navigation
Tracking issue for Path::relative_from stabilization #23284
Description
Path::relative_from removes the common prefix from a path, e.g. /foo/bar relative_from /foo yields bar.
The old path_relative_from would calculate the relative path from two points on the file system, e.g. the relative path from /foo/bar to /foo/baz/qux is ../baz/qux. This is a useful operation.
Nominating because I think either relative_from is named wrong or is not useful.
Activity
brson commentedon Mar 11, 2015
cc #23283
aturon commentedon Mar 12, 2015
cc me
aturon commentedon Mar 12, 2015
Note that the reason the new semantics was adopted has to do with symlinks (the same reason we do not normalize
..). We'll need to discuss this further, but for now it's plausible to leave this function unstable.pnkfelix commentedon Mar 19, 2015
Function is not yet stable, so this need not be milestoned. P-high, not 1.0.
lilyball commentedon Mar 23, 2015
Path::relative_frommade more sense back when we auto-normalized paths. The idea was if you joined the result to the first path, you'd get the second path. Since we don't normalize like that anymore, that behavior doesn't work.It's still a potentially useful operation, but because of symlinks, there are two different behaviors that might be desired:
baseneeds to be a prefix ofself)../components. Symlinks mean traversing thebase path and then traversing the returned relative path may not put you in the same directory that traversing theself` path does. But this operation is useful when either you're working with a path-based system that doesn't care about symlinks, or you've already resolved symlinks in the paths you're working with.Based on that I think it's reasonable to provide both implementations. The former might want to be called something like
strip_prefix()instead. the latter could continue to be calledrelative_from.[-]New Path::relative_from is less useful than old Path::path_relative_from[/-][+]Tracking issue for Path::relative_from stabilization[/+]withoutboats commentedon Aug 23, 2015
Just noting that I have found this function useful. I think it would probably make more sense to name it something like
strip_prefixthough.rgardner commentedon Nov 6, 2015
I too have found this function useful. What has to happen to stabilize this?
JanLikar commentedon Nov 15, 2015
This should be stabilized or a similar function should be proposed.
qmx commentedon Nov 30, 2015
since @mbrubeck pointed me here for my usecase too, here it comes:
I'm more than fine on renaming it to
strip_prefix.13 remaining items
BurntSushi commentedon Jan 13, 2016
I like
strip_prefix. Returning aResultseems prudent.aturon commentedon Jan 13, 2016
I'm on board with both the renaming and using
Resulthere.alexcrichton commentedon Jan 15, 2016
The libs team discussed this during triage yesterday and the decision was to stabilize with the name
strip_prefixand the tweak of returning aResult.softprops commentedon Jan 16, 2016
Is strip_prefix a different name for the same behavior found on strings?
https://doc.rust-lang.org/std/string/struct.String.html#method.trim_left_matches
SimonSapin commentedon Jan 16, 2016
@softprops
str::trim_left_matcheszero or more instances of the pattern, as many as possible.Path::strip_prefixremoves exactly one or returnsErrif there isn’t a match. It also only cuts at path separators.Rollup merge of rust-lang#30943 - alexcrichton:stabilize-1.7, r=aturon
Merge pull request rust-lang#23284 from BenjaminBrienen/update-guide-…