C++ Logo


Advanced search

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

From: Niall Douglas <s_sourceforge_at_[hidden]>
Date: Thu, 22 Aug 2019 14:28:46 +0100
CC: SG16 Unicode

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 means
that generic Ranges-based code such as:

#include <filesystem>
#include <iostream>

template< class T >
concept Range = requires(T&& t) {
  std::end (std::forward<T>(t));

template <typename T>
void print(const T& value) {
  std::cout << value;

template <Range R>
void print(const R& range) {
  for (const auto& elem: range) {

int main() {

... loops infinitely.

Seeing as LEWG endorsed in Cologne path_view departing from path's
design where it makes sense, I therefore propose a design change to
P1030 filesystem::path_view: its iterator should no longer return
another filesystem::path_view, but filesystem::path_view_component.
filesystem::path_view_component would have all the member functions
which filesystem::path_view has without those pertaining to paths of
more than one component, or iteration. These currently would proposed to be:


Note the lack of .size(), and especially begin() and end().

filesystem::path_view_component would not be constructible by public
code, only from a filesystem::path_view member function.

filesystem::path_view would implicitly construct from

Is LEWG happy with this proposed design change?


Received on 2019-08-22 15:28:49