I vote to accept the library into Boost. * What is your evaluation of the design? * What is your evaluation of the implementation? The design and implementation is clear and straightforward. Of course we'd like to have such a library with better syntax, but current C++ doesn't allow to make it better. * What is your evaluation of the documentation? Clear and understandable. * What is your evaluation of the potential usefulness of the library? I believe the library is very useful, I will use it in my work. It helps to avoid writing complex rollback code clean and in-place. Another nice feature comparing to using lambdas is the ability to place breakpoints inside the rollback code. Without ScopeExit you can only achieve this by using manually-written scope guard class from scratch * Did you try to use the library? With what compiler? Did you have any problems? Yes, played with the examples from documentation, GCC 3.4, no problems noted. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Compiled, played with examples, looked into the implementation. * Are you knowledgeable about the problem domain? I'm sure everyone is :) * Do you think the library should be accepted as a Boost library? Yes. A couple of general comments after reading other reviews. 1. The fact that the library takes all arguments by reference looks unavoidable. If it allowed passing by value (i.e. making copies) - the copy constructors can throw, and this exception will be thrown after you made the change to your container/whatever you'd like to rollback, and before you setup the rollback action. So you can't guarantee that your rollback action will be executed. So, in case you need a copy - it's much safer to create this copy before making the change to your container/whatever. It will also express your intention more clearly. 2. Of course it would be great to have a full-featured scope guard library in Boost, but its absense is not an excuse to reject ScopeExit, otherwise we need to reject scoped_ptr/scoped_array etc, as they are forms of scope guard. In general, I believe we can't reject a library A just because Boost misses a library B. Thanks, Maxim