2734. Questionable specification in [fs.path.concat]

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

1. if x is present and is const path&, x.native(); otherwise
2. if source is present, the effective range of source (31.12.6.4 [fs.path.req]); otherwise,
3. if first and last are present, the range [first, last); otherwise,
4. x

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.