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.