
On Fri, May 16, 2014 at 1:21 AM, Yakov Galka
On Fri, May 16, 2014 at 3:53 AM, Gavin Lambert
wrote:
I think most of the points you brought up here aren't really on-topic in this particular thread, and would have been better made in a separate thread (or by writing your own alternative implementation). I doubt it's likely that grand sweeping changes to an existing accepted library would get anywhere. But that doesn't mean you couldn't submit an alternative intended to supersede it; that's happened in the past.
True, some of them are off-topic. And I do have an alternative path implementation that I'm using myself, which I might release some day. However, boost.filesystem already undergone three major versions, and it is actively pushed to being standardized. So fixing it might be more logical than introducing another library, that fixes those concrete problems but presents an entirely different, likely controversial, approach.
Filesystem will be a Technical Specification initially, rather than become part of the Standard Library. Full standardization is tentatively targeted for C++17. Voting on the Filesystem TS finished in January, and the committee is expected to finish comment resolution at the June meeting in Rapperswil, Switzerland. The deadline for the pre-meeting mailing is a week from today, so there really isn't time to do more than resolve national body comments from the PDTS voting. I've started the process of updating the Boost implementation and documentation to conform to the TS. Some of that will go in 1.56, with anything not finished in time will got in 1.57. --Beman