Hi all, A few weeks ago, there was a request to remove boost::function's dependency on boost::throw_exception when the user ensures that boost::function is always initialized before attempting a call. https://svn.boost.org/trac/boost/ticket/4646 Providing an alternative invocation method in addition to the call operator is an unattractive solution for many reasons; e.g. boost::function would be less function-like syntacticly. Instead, why not provide an alternative function wrapper with no exception safety guarantee and no dependency on boost::throw_exception? Thanks to Boost.Function's implementation design, which uses preprocessor metaprogramming to generate many function wrappers with different arities, it is simple to generate a function wrapper with no exception safety guarantee. I have submitted a feature request with a patch that implements boost::unsafe_function -- a function wrapper with no exception safety guarantee -- along with tests and updated documentation. https://svn.boost.org/trac/boost/ticket/4720 unsafe_function's API and semantics are identical to boost::function except that the behavior of operator() is undefined when uninitialized. Also, swap, constructor and assignment operators have been added to allow an unsafe_function to wrap the target of a boost::function and vice versa. unsafe_function is primarily useful in certain environments in which exceptions and/or compiler optimizations are unavailable, such as some embedded systems. On contemporary PC hardware, unsafe_function typically would not have an advantage over boost::function. For example, with object code generated by gcc -O2, I could only detect a ~1% difference between the two in terms of runtime costs using a simple benchmark; i.e. less than a nanosecond. However, with -O1, unsafe_function costs ~15% less than boost::function due to the lack of overhead from the strong exception safety guarantee. Thoughts? Daniel Walker