Clarify design purpose of separate handler_type and async_result

[chriskohlhoff]

[chriskohlhoff]

Pre-Lenexa Summary

[async.handler.type], [async.async.result]

The question is whether completion_handler_type and async_result need to be separate.

In the original implementation of these traits handler_type (as it was then known) was also responsible for automatically decaying the CompletionToken. However, in the Cologne review we determined that the decay needed to be performed by the helper class async_completion, and that only object types be passed to completion_handler_type.

I reviewed my original design notes and related proposals and could not find any other reason to retain a separate completion_handler_type.

If they are to be combined then an archetypal async_result would look like this:

template <class CompletionToken, class Signature>
class async_result
{
public:
  // The return type of the initiating function.
  typedef ... return_type;

  // The type of a completion handler.
  typedef ... completion_handler_type;

  // Construct from a given handler.
  explicit async_result(completion_handler_type& h);

  // Obtain the value to be returned from the initiating function.
  return_type get();
};

I prototyped this and it seems to work ok. My preference is to make the change assuming no showstoppers.