Core rationale: Parsing paths correctly seems easy but is surprisingly hard and bug prone in the general case. Even on Darwin, it's an extremely small set of developers that understand how paths really parse. I have recently become a member of that small set; it's not something I'd want other developers to have to learn just to do very simple things like pop components off of a path. This is somewhat analogous to Unicode correctness, which seems easy at times but in practice is not something you want to have to reinvent.
On Linux, it's fairly easy. If you keep popping components off of /foo/bar you end up at / and then the operation becomes idempotent. On Darwin, if you keep popping components off of /.nofollow/foo/bar the fixed point is /.nofollow/, not /. Similarly, /.vol/123/456/foo/bar would be /.vol/123/456 (note: no slash at the end). Furthermore, /.resolve/1/ is a syntactic alias for /.nofollow/, etc. None of this is obvious without having niche expertise in the XNU kernel.
As for the existence of Anchor and suffix information: it is semantically relevant and part of FilePath's semantic model (e.g. ==). If FilePath were to internally parse paths correctly, but only expose the ComponentView (or even just push/pop components off the sequence of relative path components) and not expose Anchor or suffix information, then it would be hiding semantically-relevant information from the developer. E.g., in some domains, developers might want to strip a trailing slash, so we provide interfaces to do so. Similarly, resource forks are part of FilePath's semantic model (and naively look like relative path components even though they are not). Hiding their presence would force developers into using the C-bridging or byte-level interfaces to manually parse them and then do byte splicing and path reconstruction. Having dealt with the corner cases involved myself, I would not wish this fate even on my foes.
Will do. Thanks for pointing this out.
This is why FilePath and the stdlib should be responsible for correctly parsing paths. FilePath will stay up to date with changes in, e.g., the XNU kernel. It is unreasonable to expect developers to write their own parsers and keep them up to date.
Could you elaborate on this example or this need? I'm not sure I fully understand.
FilePath.ComponentView is RRC, so you can get the last relative path component, remove it, append a new one (or collection of components), etc. An earlier pitch had a slew of syntactic API directly on FilePath and those are deferred as future work to focus on the essential: parsing paths correctly on behalf of the developer without hiding semantically-relevant portions or bits.
We include non-syntactic resolve() because of the strong urging from the security community that, analogous to how parsing paths is surprisingly hard, resolving paths is surprisingly hard and bundling this with FilePath from day 1 is essential for security purposes.
I believe the RRC conformance gives you the tools necessary to implement syntactic operations, but it may be worth prioritizing (in a follow up proposal) a set of important syntactic operations or conveniences, such as joining paths, with defined semantics around all the corner cases that come up (corner cases that often can only be described in terms of Anchor).
Could you elaborate or describe what the ask is? If you're referring to the POSIX prefix for implementation-defined path syntax, e.g. how cygwin represents Windows paths, that's future work for the relevant platform.
I want to make sure we are not conflating multiple things here. \\.\ is the device namespace, to which Microsoft could certainly add things, but which has a well-defined parsing. The content before a separator is the device (part of the anchor); the content after is not. \\?\ designates a different path syntactic form (and lifts path length requirements if applicable, which is vital for many libraries) but still has a well-defined parse (noting that the equivalent of \\srv\shr is \\?\UNC\srv\shr). All of these are Win32 paths in that they go through Win32 API. FilePath does not model NT object-manager paths (e.g. \??\ and many other forms), which are something else entirely and do not go through Win32 API.