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.

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

Section: 29.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:

29.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` (29.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 (29.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 29.12.6.3.2 [fs.path.type.cvt] seems to imply that any format conversion specified in 29.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 (29.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.