Klaim - Joël Lamotte
So basically you suggest to require the filesystem implementation concept to be able to work with boost::filestystem::path, but not restrain using a more filesystem-specific version of path, if it makes sense for this filesystem.
Yes. boost::filestystem::path may implement _more_ than the concept requires, of course.
boost::filesystem::path would just be the default path type, but not the only one usable depending on the filesystem implementation.
I wouldn't say the default type. There isn't really a default. Each filesystem specifies its implementation of FilesystemPathConcept using a typdef. A filesystem without this typedef would not model FilesystemConcept.
Also, what is your intent with the draft exactly? Do you want to provide such modifications? (as a PR maybe?) Or are you asking the maintainer to do it because you don't feel that you can yourself?
I intend to do all the changes to Boost.Filesystem myself, as time permits, as well as (non-Boost) implementations of an SFTP filesystem (partially complete) and a 7z filesystem (not yet started). The point of discussing the draft here is to make sure Beman, and any other interested parties, agree the changes make sense, and to get important feedback before I get too far ahead. Already your few questions have made the role of the path classes much clearer in my head, so thanks! Alex