1. Should Boost.AFIO be accepted into Boost?
The topic of asynchronous file operation is very very important and quite critical in our days. Boost needs such a library but I fear *current* AFO is not there yet. I vote NO for its inclusion in Boost in its current form.
2. What is your evaluation of the design?
I think the intent are goods but there's some icky parts. The use of future and other asynchronous element in the API cudl be made more clear and easy. Thomas Heller made a compelling lsit of gotcha that shoudl be followed. Currently i had to fight against my habit of writing future absed code to get the stuff working.
3. What is your evaluation of the implementation?
Next to small scale issues like mammoth headers and liberal use of allocation in the implementation of some functions, I think the main culprit is to simplify the implementation by splitting the ABI stable part into another component. Also, the way asynchronous cmponents are used internally hould be aligned with the required fix on the public API.
4. What is your evaluation of the documentation?
The documentation is hard to follow and some 'simple example' are clearly not that simple. This should be the second major point of improvement.
5. What is your evaluation of the potential usefulness of the library?
THis kind of library is very useful and as I said, we need one with proper design and implementation.
6. Did you try to use the library?
Played around with the examle and the doc.
7. How much effort did you put into your evaluation?
Roughly 10-12 hours
8. Are you knowledgeable about the problem domain?
Not with async file I/O but I have a fair amount of experience in asynchronous computation and parallel programming in general. As a concluding note, I *really* want Niall to keep going on making AFIO the reference async file I/O library. Just take the needed time to reflect on the afformentionned PAI and implementation issues and remember that there is no rush to get there.