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

Section: 30.11.7.4.4 [fs.path.concat] Status: New Submitter: Tim Song Opened: 2016-06-16 Last modified: 2017-03-19

Priority: 2

View all issues with New status.

Discussion:

30.11.7.4.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 (30.11.7.3 [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 (30.11.7.2.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 30.11.7.2.2 [fs.path.type.cvt] seems to imply that any format conversion specified in 30.11.7.2.1 [fs.path.fmt.cvt] will not be performed, in seeming contradiction to the rule that native() is to return the native pathname format (30.11.7.4.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:

The wording for LWG 2798 resolves this issue as well.