[ 2013-04-14 STL provides rationale ]

Rationale:

I've concluded that Scott's original proposed resolution was correct and complete. There are two sides to this story: the producers and the consumers of these typedefs.

Producers: As Scott noted, the Standard clearly documents which function objects must provide these typedefs. Some function objects must provide them unconditionally (e.g. plus<T> (for T != void), [arithmetic.operations]/1), some conditionally (e.g. reference_wrapper<T>, [refwrap]/2-4), and some don't have to provide them at all (e.g. lambdas, [expr.prim.lambda]). These requirements are clear, so we shouldn't change them or even add informative notes. Furthermore, because these typedefs aren't needed in the C++11 world with decltype/perfect forwarding/etc., we shouldn't add more requirements to provide them.

Consumers: This is what we were concerned about at Portland. However, the consumers also clearly document their requirements in the existing text. For example, reference_wrapper<T> is also a conditional consumer, and [refwrap] explains what typedefs it's looking for. We were especially concerned about the old negators and the deprecated binders, but they're okay too. [negators] clearly says that unary_negate<Predicate> requires Predicate::argument_type to be a type, and binary_negate<Predicate> requires Predicate::first_argument_type and Predicate::second_argument_type to be types. (unary_negate/binary_negate provide result_type but they don't consume it.) [depr.lib.binders] behaves the same way with Fn::first_argument_type, Fn::second_argument_type, and Fn::result_type. No additional wording is necessary.

A careful reading of [function.objects]/5 reveals that it wasn't talking about anything beyond the mere existence of the mentioned typedefs — for example, it didn't mention that the function object's return type should be result_type, or even convertible to result_type. As the producers and consumers are certainly talking about the existence of the typedefs (in addition to clearly implying semantic requirements), we lose nothing by deleting the unnecessary paragraph.