[SG16-Unicode] [isocpp-lib-ext] Proposed design change to P1030 filesystem::path_view

Arthur O'Dwyer arthur.j.odwyer at gmail.com
Mon Aug 26 03:14:02 CEST 2019


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 lists.isocpp.org> 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 lists.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/08/12453.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/unicode/attachments/20190825/5266cb8a/attachment.html 


More information about the Unicode mailing list