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.
generic*?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 thepath 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: