I know we have AdaptableUnaryFunction, which covers function objects with nested result_type and argument_type. But we've long since learned that argument_type is really unnecessary, and plenty of libraries are looking at result_type alone (e.g. bind). Do we have a concept for that sort of function object? If not, what shall we call it? Should we rather invent a concept for "UnaryFunction that works with boost/tr1::result_of<>" ? Maybe DeducibleUnaryFunction? -- Dave Abrahams Boost Consulting www.boost-consulting.com