Re: [Boost-users] [filesystem] Relative Draft Proposal RFC

Subject: Re: [Boost-users] [filesystem] Relative Draft Proposal RFC
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-19 20:32:44

On 20/08/2015 02:55, Beman Dawes wrote:
> The full proposal is at
> http://boostorg.github.io/filesystem/relative_proposal.html
>
> A preliminary implementation is available in the feature/relative2
> branch of the Boost Filesystem Git repository. See
> github.com/boostorg/filesystem/tree/feature/relative2
> <http://github.com/boostorg/filesystem/tree/feature/relative2>
>
> The overall plan is to get feedback from boost developers, then merge to
> develop for boost 1.60, then propose to the C++ committee for addition
> to the Filesystem TS.
>
> Comments welcome. If you are one of the many people who have requested
> "relative" functionality, does this proposal meet your needs? If not, why?

Looks good so far.  (I've only looked at the proposal document, not the 
code.)

There's a few things that strike me as curious (I'm sure there are 
reasons for them though):

1. Why is the normal form for "/some/path/" equal to "/some/path/." 
instead of "/some/path"?  Doesn't that violate the "no redundant current 
directory elements" rule?  (I assume it's related to the root path being 
weird, but maybe it would be better to make the root path an exception 
rather than cluttering the general case?)

2. For relative(path), it appears to be unspecified (at least in the 
example assertions) what happens when unrelated paths are used.  I would 
expect the following:
    path("/a/b/c").relative("/d/e/f") == path("../../../a/b/c")
    path("/a/b/c").relative("d/e/f") == path() or exception
    path("a/b/c").relative("/d/e/f") == path() or exception
    path("a/b/c").relative("d/e/f") == path() or exception
  (Arguably the second might not be an error -- provided the first path 
is absolute [which isn't true for the above on Windows] then it could 
return the first path without modification; this would still technically 
be a valid path but it wouldn't be a relative one, which is why I think 
an error is more appropriate.)

3. "Throws: As specified in Error reporting."  I assume this refers to 
some other document, as it does not appear to refer to anything in this 
one.  Also it seems odd that this clause is omitted on the earlier 
functions.