Re: [filesystem] becoming worse than the standard?

From: Alan de Freitas (alandefreitas_at_[hidden])
Date: 2022-08-15 18:54:58

>
> It's less clear what should happen when the library calls append or assign
> with
> iterators whose value_type is char on something whose value_type is
> wchar_t,
> which is what you seem to be doing.

> std::filesystem requirements[2] actually restrict Source arguments to
> std string types, iterators (read: pointers) to C-style strings and
> arrays of characters (which are interpreted as C-style strings).

Yes. That sounds right. It looks like boost::filesystem is matching the
behavior of std;:filesystem now, even if more restrictive (
https://godbolt.org/z/5WYYce6v8).
Boost.URL shouldn't use it and that's for the best, since std::filesystem
doesn't support it either.

Non-contiguous ranges that dereference to char work with both std:: and
boost::filesystem if we use the `append(InputIterator begin, InputIterator
end)` overload.
I think that's the source of confusion here. What C++ says about the
`append(Source const& source)` overload is even more misleading.

(2) and (3) participate in overload resolution only if Source and path are
not the same type, and either:

   - Source is a specialization of std::basic_string
   <https://en.cppreference.com/w/cpp/string/basic_string> or
   std::basic_string_view
   <https://en.cppreference.com/w/cpp/string/basic_string_view>, or
   - std::iterator_traits
   <http://en.cppreference.com/w/cpp/iterator/iterator_traits><std::decay_t
   <http://en.cppreference.com/w/cpp/types/decay><Source>>::value_type is
   valid and denotes a possibly const-qualified encoding character type (
   char, char8_t, (since C++20)char16_t, char32_t, or wchar_t).

We assumed both overloads should work because of this second condition.

> 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.
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.

Thank you for the explanation.

Em seg., 15 de ago. de 2022 Ã s 14:24, Andrey Semashev via Boost <
boost_at_[hidden]> escreveu:

> On 8/15/22 20:14, Alan de Freitas via Boost wrote:
> >>
> >> Assigning or constructing a path
> >> from e.g. std::list<char> doesn't make much sense,
> >
> > Why not?
>
> Because list is not a string. If you're assigning a list to a path, most
> likely you are doing something wrong.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Alan Freitas
https://github.com/alandefreitas