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.

[ 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. ]

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

[ 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.

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.