A single path is not conceptually a "range" of *anything* — it's just a
single filesystem path.
C++17 made the mistake of giving "begin" and "end" methods to
`std::filesystem::path`, so that to C++ a std::filesystem::path *looks*
like a range of paths.
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()) { ... }

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

Thanks,
–Arthur



On Thu, Aug 22, 2019 at 9:45 AM Herring, Davis via Lib-Ext <
lib-ext_at_[hidden]> wrote:

> > It has been brought to my attention by Victor Zverovich that
> > filesystem::path has an unfortunate quirk wrt Ranges:
> > filesystem::path::iterator::value_type is filesystem::path.
>
> This was (my) Late 19 comment for C++17. (At the time, I proposed just
> using string for the individual components, but it's still helpful to have
> path's encoding support.) It's also a famous pitfall in Python:
>
> def depth(x,f): # apply f to all leaves
> try: x=iter(x)
> except TypeError: f(x)
> else:
> for e in x: depth(e,f)
>
> depth("a",id) will recurse forever because list("a")[0]=="a".
>
> Davis
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/08/12453.php
>