It would be nice to have a way to make sure a directory_iterator does not open a symlink to a directory; maybe by adding a function to get a directory_entry structure of the root directory, or by adding another constructor. Currently it is possible to do this:

fs::path root("root");
fs::recursive_directory_iterator iter;
if (!fs::is_symlink(root)) {
     iter = fs::recursive_directory_iterator(root, fs::symlink_option::no_recurse);
}

However, there is a race condition here: After having checked that root is not a symlink, the world may change and the constructor may open a symlink.

That does not feel good. But a 'traditional' global error code makes thread-safe coding hard.

My suggestions are:

1. Add an error_code member to directory_entry, *directory_iterator, and provide a member function like is_valid() for user to check the status;
2. Move the non-member operational functions into a context class, so that the error code can be managed in the same way.

Description

Daniel Krügler [c++std-filesystem-29]

IMO the range-support for [recursive_]directory_iterator should be deferred.
The presented technique is IMO an unfortunate "hack" and should be
replaced by factory functions returning a
std::range<[recursive_]directory_iterator>.

The std::range is IMO the much better solution for this and idiomatic.

Yes, we have not yet std::range, but we nearly got that via a last-minute
proposal for C++11. I hope, this time we have a bit more time to make
a full-fledged
proposal.

I would strongly recommend to defer the range-support instead. We can work with
these iterators, they are not broken, several existing iterators
provide no direct
support for the range-for-loop. It is not a shame that
[recursive_]directory_iterator
would not at the initial proposal.

Adding a "cleaner" way via factory functions returning a
std::range<[recursive_]directory_iterator>
can be easily down slightly later.

Discussion

[Beman] I believe the Filesystem library should become a Technical Specification, and as such should rely only on C++11 features.

Deciding if the target is a TS or is C++1y needs to be deferred to a committee meeting so that input from the LWG (and possibly the EWG) is available. Thus an issue is being opened so Daniel's proposal isn't forgotten.