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.
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:
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]
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 namedcharTEcharTshall be one of the encoded character types.