title: Why does std::filesystem provide so many non-member functions?
body: <p>Consider for example 
  <a href="http://en.cppreference.com/w/cpp/experimental/fs/file_size" rel="noreferrer"><code>file_size</code></a>. To get the size of a file we will be using</p>
  
  <pre><code>std::filesystem::path p = std::filesystem::current_path();
  // ... usual "does this exist &amp;&amp; is this a file" boilerplate
  auto n = std::filesystem::file_size(p);
  </code></pre>
  
  <p>Nothing wrong with that, if it were plain ol' C, but having been taught that C++ is an OO language [I do know it's multi-paradigm, apologies to our language lawyers :-)] that just feels so ... <em>imperative</em> (shudder) to me, where I have come to expect the object-ish</p>
  
  <pre><code>auto n = p.file_size();
  </code></pre>
  
  <p>instead. The same holds for other functions, such as <code>resize_file</code>, <code>remove_file</code> and probably more.</p>
  
  <p>Do you know of any rationale why Boost and consequently <code>std::filesystem</code> chose this imperative style instead of the object-ish one? What is the benefit? Boost <a href="http://www.boost.org/doc/libs/1_63_0/libs/filesystem/doc/faq.htm" rel="noreferrer">mentions the rule</a> (at the very bottom), but no rationale for it.</p>
  
  <p>I was thinking about inherent issues such as <code>p</code>s state after <code>remove_file(p)</code>, or error flags (overloads with additional argument), but neither approach solves these less elegant than the other.</p>
  
  <hr>
  
  <p>You can observe a similar pattern with iterators, where nowadays we can (are supposed to?) do <code>begin(it)</code> instead of <code>it.begin()</code>, but here I think the rationale was to be more in line with the non-modifying <code>next(it)</code> and such.</p>