Tracking Issue for `normalize_lexically`

[ChrisDenton]

View all comments

Feature gate: #![feature(normalize_lexically)]

This is a tracking issue for Path::normalize_lexically that is used to normalize a path, including .. parent references, without touching the filesystem.

Public API

// std::path

impl Path {
    pub fn normalize_lexically(&self) -> Result<PathBuf, NormalizeError> {
}

Steps / History

• API Change Proposal
• Implementation: Implement normalize_lexically #134696
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Should PathBuf have a method that normalizes in-place? Normalizing a path just removes components.
• Should this disallow resolving to the empty path or the single . path.
• Should this only allow paths without a root or prefix? It may be surprising that base_path.join(user_path.normalize_lexically()?) can still escape the base path.

The last two can be summarised as: should this strictly require paths to be sub-paths?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[ChrisDenton]

The basic implementation is now implemented in nightly if people would like to experiment.

[clarfonthey]

Should this take &mut self and normalize in-place? Normalizing a path just removes components.

This could be done for PathBuf, but &mut Path cannot actually delete anything, since the resulting path has to be the same length. Maybe it could be done in a way similar to partition_dedup where all the components are moved to the end, but that would be confusing and a PathBuf-based method sounds much better API-wise.

[ChrisDenton]

We could have a function both on Path and PathBuf. The only issue would be choosing names to distinguish them. normalize_lexically is already a bit of a mouthful (somewhat intentionally since it shouldn't be what people reach for by default).

[clarfonthey]

How would you do a function on Path that removes components of the path in-place, given what I mentioned?

[ChrisDenton]

No, I meant have a function on Path that returns a PathBuf and a separate function on PathBuf that does in-place normalisation.

[clarfonthey]

Ah, yeah, that makes sense. I was mostly commenting on the note at the end that taking &mut self would only work on PathBuf, meaning that it would be worthwhile to have both.

[ChrisDenton]

I've updated it to suggest adding a method to PathBuf instead. If anyone wants to implement that then feel free, I probably won't get to it for awhile.