This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 8.4.7 [filesys.ts::path.generic.obs] Status: NAD Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2016-08-12
Priority: Not Prioritized
View all issues with NAD status.
Discussion:
Addresses: filesys.ts
Do we really need generic*?
[2014-02-08 Daniel comments]
These functions should exist for more than one reason.
First, the generic pathname format is a well-defined concept for the path specification and defining just a single way into a path but not out of it looks like an incomplete design. More importantly, the existence of these functions have demonstrated to be quite useful in practice, because the generic pathname format concept is popular for many tools such as maven or the some configuration files for the Eclipse IDE do understand this syntax uniformly on all platforms and it allows to generate or modify such files using C++ code based on filesystem::path. The practical problem of the non-portable root-names doesn't matter in such contexts, because the serialized path names are in general relative names or depend on initial parts that are determined by properties or environment variables. In other words: I'm recommending NAD for this issue.[2014-02-13 LWG/SG-3 Issaquah: Withdrawn by submitter.]
Proposed resolution: