Re: [filesystem] becoming worse than the standard?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-08-15 10:37:30

On 8/15/22 02:34, Vinnie Falco via Boost wrote:
> I see this in the commit log for boost.filesystem:
> 
>     Deprecated path construction/assignment/appending from container types.
>     Users are advised to use string types and iterators instead of containers
>     to construct/assign/append to paths.
>     In v4, the support for containers is removed.
> 
> This can't be right now, can it? Because std::filesystem supports path
> construction from anything meeting the requirements of Source which is
> kind of range-like.

Paths are supposed to interoperate with strings, so that is what the
change you refer to[1] is aimed for. Assigning or constructing a path
from e.g. std::list<char> doesn't make much sense, and that is being
deprecated. That Boost.Filesystem used to accept this is an unfortunate
legacy misfeature, which is being removed. Note that the support for
string types is *not* being removed.

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). So
Boost.Filesystem is getting closer to the standard here.

> Boost.URL and its downstream libraries HTTP-Proto,
> HTTP-IO, Websocket-Proto, and Websocket-IO are depending on the
> container-based interface to achieve reasonably decent syntax and
> semantics despite the limitations of the path API (which are the fault
> of the standard and not Boost).

Could you describe why you need to construct/assign/append to paths from
arbitrary containers and why you cannot use string types or iterators?

[1]:
https://github.com/boostorg/filesystem/commit/d829a46b3120933e3dbaf9b3c85bf1dc1ec8e77c
[2]: http://eel.is/c++draft/fs.path.req#1