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.

### 2646. [filesys.ts] [PDTS] Do we really need `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 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: