Re: [filesystem] becoming worse than the standard?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-08-29 21:57:50

On 8/15/22 23:41, Andrey Semashev wrote:
> On 8/15/22 21:54, Alan de Freitas via Boost wrote:
> 
>>> If you're assigning a list to a path, most
>>> likely you are doing something wrong.
>>
>> Yes. `append(InputIterator begin, InputIterator end)` would still allow the
>> person to do this wrong thing though.
>>
>> And `append(InputIterator begin, InputIterator end)` doesn't look like it's
>> always wrong.
> 
> The signature with two iterators is the established practice for
> obtaining elements from a foreign sequence. You have it in every std
> container, std::string, etc. In particular, it allows to obtain the
> elements from exotic sources, like reading from an
> std::istreambuf_iterator. There is no such practice with a
> single-argument signature.
> 
>> Two obvious use cases could be (i) appending paths from resource trees or
>> (ii) some std::ranges::view::... that transforms the input into the chars
>> to represent a path segment for that input.
>> If `append(InputIterator begin, InputIterator end)` is not wrong, it looks
>> like `append(Source const& source)` would not be less wrong when Source is
>> just the range holding the iterators for the first overload.
>>
>> In any case, both are still dangerous. Boost.URL and other libraries
>> shouldn't count on it.
>> As Peter mentioned, things like wstring and u16string could be appended,
>> but the semantics will probably be wrong.
>> They will convert char by char, without regards of encoding.
> 
> If the user calls a function passing two iterators, he is arguably aware
> that he is constructing/assigning/appending elements one-by-one,
> performing element-wise conversion, if needed. Again, this is
> established practice.

Actually, I was incorrect on this one, at least wrt.
std::filesystem::path. It only accepts iterators that have value_type
that is one of the path character types.