This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 31.12.6.5.4 [fs.path.concat] Status: Resolved Submitter: Tim Song Opened: 2016-06-16 Last modified: 2018-01-24
Priority: 2
View all other issues in [fs.path.concat].
View all issues with Resolved status.
Discussion:
31.12.6.5.4 [fs.path.concat] specifies that the postcondition for
path& operator+=(const path& x); path& operator+=(const string_type& x); path& operator+=(const value_type* x); path& operator+=(value_type x); template<class Source> path& operator+=(const Source& x); template<class EcharT> path& operator+=(EcharT x); template<class Source> path& concat(const Source& x); template<class InputIterator> path& concat(InputIterator first, InputIterator last);
is
native() == prior_native + effective-argument
where effective-argument is
It also says that
If the value type of effective-argument would not be path::value_type, the actual argument or argument range is first converted (31.12.6.3.2 [fs.path.type.cvt]) so that effective-argument has value type path::value_type.
There are several problems with this specification:
First, there is no overload taking "source" (note the lower case); all single-argument overloads take "x". Second, there's nothing that defines what it means to use operator+ on a string and an iterator range; clearly concatentation is intended but there is no wording to that effect. Third, the final portion uses "value type", but the "value type" of a single character is not a defined concept. Also, the reference only to 31.12.6.3.2 [fs.path.type.cvt] seems to imply that any format conversion specified in 31.12.6.3.1 [fs.path.fmt.cvt] will not be performed, in seeming contradiction to the rule that native() is to return the native pathname format (31.12.6.5.6 [fs.path.native.obs]/1). Is that intended?[2016-11-10, Billy suggests wording]
The wording for LWG 2798 resolves this issue as well.
Proposed resolution:
This is resolved by p0492r2.