This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of TS status.

### 2648. [filesys.ts] [PDTS] `path::template<class charT>string()` conversion rules

Section: 8.4.6 [filesys.ts::path.native.obs] Status: TS Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2017-07-30

Priority: Not Prioritized

View all issues with TS status.

Discussion:

Addresses: filesys.ts

`path::template<class charT>string()` should promise to convert by the same rules as `u16string` for `string<char16_t>`, etc. and one-for-one otherwise.

What if `charT` is `signed char` (or even `float`)? I don't see where that choice is disallowed, so we should either disallow it or make it be something that is quasi-sensible.

[2014-02-08 Daniel comments]

There are two relevant places in the wording that seem to clarify what is required here:

1. Most importantly, 5 [fs.req] says:

   > Throughout this Technical Specification, `char`, `wchar_t`, `char16_t`, and `char32_t` are collectively called encoded character types.

   > Template parameters named `charT` shall be one of the encoded character types.

   > […] [Note: Use of an encoded character type implies an associated encoding. Since `signed char` and `unsigned char` have no implied encoding, they are not included as permitted types. — end note]

2. For both the mentioned `string` function template and the specific non-template functions (such as `u16string()`) the same `Remarks` element exists, that refers to character conversion:

   > Conversion, if any, is performed as specified by 8.2 [path.cvt].

The first quote excludes arbitrary types such as `signed char` or `float` as feasible template arguments. The second quote makes clear that both the function template and the non-template functions do normatively refer to the same wording in 8.2 [path.cvt].

Based on this interpretation of the issue discussion I recommend resolving it as NAD.

In addition to that recommendation I recommend to rename the current usage of the symbol `charT` in this technical specification, because 5 [fs.req] assigns a very special meaning to the constraints on `charT` types that does not exist to this extend in the rest of the standard library. A similar approach is used in Clause 22, where a special symbol `C` is used for constrained character types (C++11 §22.3.1.1.1 [locale.category]):

> A template formal parameter with name `C` represents the set of types containing `char`, `wchar_t`, and any other implementation-defined character types that satisfy the requirements for a character on which any of the `iostream` components can be instantiated.

[2014-02-28 Beman provides proposed resolution wording]

[18 Jun 2014 Beman changes proposed name from C to EcharT in response to tentative vote concern that C was insuficiently informative as a name.]

Proposed resolution:

In the entire Working Paper, except in the synopsis for path inserter and extractor and 8.6.1 path inserter and extractor [path.io], change each instance of "`charT`" to "`EcharT`".

For example, in 5 [fs.req]:

> Template parameters named `charT` `EcharT` shall be one of the encoded character types.