Subject: Re: [SG16-Unicode] [isocpp-lib-ext] Proposed design change to P1030 filesystem::path_view
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-08-27 06:46:40
On 26/08/2019 20:28, Arthur O'Dwyer wrote:
> A path /*itself*/ is not a range of anything â it's just a path.
> std::filesystem::path breaks this intuition by giving
> std::filesystem::path ".begin()" and ".end()" methods, which causes C++
> to treat it like a range type. But that's just an example of "lying to
> the compiler." Giving .begin() and .end() methods to a C++ class type
> that does not itselfÂ /*represent*/ a range of elements was the original sin.
What ended up as std::filesystem::path underwent many peer reviews at
Boost. If I remember rightly, path's ideal design was one of the most
contentious parts of those reviews. It sharply divided expert opinion,
and Beman completely redid the design based on that feedback at least once.
Would I personally have designed filesystem::path differently? Absolutely.
Would every single person at Boost have designed filesystem::path
Did the present filesystem::path design reach a point where everybody in
the room didn't completely hate it? Indeed it did. And that is what's in
the standard today.
Committees very rarely achieve perfect design, but they do by definition
reach an acceptable design. That is std::filesystem::path, warts and all.
SG16 list run by email@example.com