Again, only half-way true. The _design_ of the whole library is changing under our noses (not just parts of the implementation) while we're supposed to make an educated decision whether this library is ready for Boost or not.
What has actually changed in the presented library?
1. outcome<T>/result<T> has been renamed to checked_optional_outcome<T>/checked_optional_result<T>.
2. A few extraneous member functions and types have been removed.
3. A few bug fixes not affecting the public API.
Other than those, nothing has changed from the presented library. I agree all this discussion and noise makes it seem more has happened, but most of that discussion is speculative. I have only agreed to the above changes only.
I believe the following email is outlining the plan on how the library has to be changed based on review feedback: http://tinyurl.com/y9n2xpjh. It was written by you, Niall, wasn't it?
Once upon a time a Boost review was supposed to refer to a single fixed source code version and not a moving target as it is for this library. The decision whether somebody would like to see a library accepted into Boost or not should not be based on wishful thinking (that the author will implement things eventually) or on unsubstantiated promises.
Most of the wishful thinking has come from reviewers wanting to redesign the library according to their preferences.
There is no moving target here. What has been presented for review is what will be accepted into Boost if acceptance is recommended.
You plan for the library to be changed massively in the near future (in API, design, and implementation). So even _you_ are not happy with it. So why accept or reject now if we don't know what the outcome (pun intended) will be? I'd like to repeat my suggestion for the review manager to consider rescheduling this review without an acceptance decision now. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu