我在gcc 6.3.1中使用了实验性std::filesystem实现，并针对std::experimental::filesystem::directory_iterator和std::distance遇到了一些非常意外的行为。具体来说，在调用std::distance之后，原始迭代器似乎已被修改。
在尝试在我的代码中找到逻辑错误的一堆无结果的调试之后，我开始在directory_iterator的实现中挖掘，最后发现迭代器在内部使用std::shared_ptr，有一个默认的copy-constructor，我假设operator++必须直接递增托管指针。
以下代码重现了该问题：
#include <iostream>
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
int main() {
auto it = fs::directory_iterator("/etc");
std::cout << *it << std::endl;
std::distance(it, fs::directory_iterator{});
std::cout << *it << std::endl;
}
由于这种实现产生了极其反直觉的结果，每当传递给一个期望迭代器具有传统值语义的函数时（据我所知，所有的STL算法），我很难相信这是预期的行为，但我不愿意称错。
显然，这个API在发布时是实验性的，但我认为它的目的是忠实地实现文件系统TS。我没有访问具有完全C++17支持的编译器，所以我一直希望在这段时间内使用它。
这是预期的行为吗？我希望directory_iterator在将来的版本中以这种方式工作吗？目前我想我可以使用boost::filesystem。
谢谢！