I'm submitting an early review of the proposed Boost.ScopeExit library, since I won't be able to do anything with it during the proposed review period. First, I really like this proposal, and think it should be accepted into Boost. I've been interested in it since I first saw it discussed on the developers list, and proposed having our group adopt its use as soon as we updated to a version of Boost that supported it, even if this proposed library was itself not yet included. I've read the current documentation and think it is quite good. I imagine some people might think that having the transaction cleanup actions next to the start of the transaction clutters the main line of execution code with "exception handling" code. However, as a long-time user of various programming languages with "finally" style cleanup actions after a protected body (various Lisp dialects, Java, Python), I've often found that having the cleanup action far removed from what is to be cleaned up makes it difficult to ensure during maintenance that the cleanup actions are always being updated appropriately. A common solution to that problem is to break the protected body out into a helper function to reduce that lexical separation. But, that's no less intrusive than registering the cleanup actions before the body. I've written some code snippets in the style of this library just to get an idea of the look, and I like the result. I've seen a lot of blatantly exception unsafe code in the couple of years I've been using C++, and my impression is that at least some of the reason for it is the syntactic inconvenience of doing things right. This library provides a superb wrapper around that inconvenient syntax. It would be better if the values needed by the cleanup body could just be referenced lexically, without the need for the scope-exit-args-pp-seq, but that's a language change (or perhaps some extremely non-portable implementation code), not a library. My only (mild) quibble is the decision to use a PP sequence for the arguments. I might prefer that this library be forward looking and assume variadic macros, with backward compatibility variants that use the PP sequence technique for use by those who need to support compilers that don't support variadic macros. I haven't actually used this library yet; I'm in the process of upgrading my group's project from boost 1.33.1 to boost 1.34.1 even as I type this, and probably won't have a chance to use it before the vacation that is the reason for this early review. Once I get back I'll be trying it out on some more recent versions of gcc than those noted in the documentation as having been tested.