On 26/08/2019 02:14, Arthur O'Dwyer wrote:
> A single path is not conceptually a "range" of /*anything*/ — it's just
> a single filesystem path.

filesystem::path defines that it is a range of filesystem path
components. Apart from the native path separator being a valid character
in a path component on some systems, I find that a reasonable design choice.

> What it should have done was to give `std::filesystem::path` one or more
> "range accessor" methods:
> for (auto&& component : mypath.components()) { ... }
> for (auto&& character : mypath.str()) { ... }

Or iteration returns a path_component type, as Victor suggested.

This approach retains much more compatibility with existing code using
filesystem::path, so that's what path_view is doing as well.

> Niall, if you are actively pursuing `path_view` for C++2b, please try to
> avoid making the same mistakes that <filesystem> made!

LEWG indicated that it wishes for path_view to breaking-deviate from
path where it makes sense e.g. .remove_filename() is a mutating member
function in path, but is non-mutating in path_view.

They have not yet considered the path_view_component approach, but I
will be recommending it over other choices e.g. .components().

My recommendation is based on easing the upgrade of filesystem::path
code. Disabling path component iteration I don't think is worth the
pain, personally.

Niall