Date
2010-12-07.00:00:00
Message id
5465

Content

Issue 2017 points out some incorrect usages of result_of in the declaration of the function call operator overload of reference_wrapper, but there are more such specification defects:

  1. According to [func.bind.bind] p. 3:

    [..] The effect of g(u1, u2, ..., uM) shall be INVOKE(fd, v1, v2, ..., vN, result_of<FD cv (V1, V2, ..., VN)>::type) [..]

    but fd is defined as "an lvalue of type FD constructed from std::forward<F>(f)". This means that the above usage must refer to result_of<FD cv & (V1, V2, ..., VN)> instead.

  2. Similar in [func.bind.bind] p. 10 bullet 2 we have:

    if the value of is_bind_expression<TiD>::value is true, the argument is tid(std::forward<Uj>(uj)...) and its type Vi is result_of<TiD cv (Uj...)>::type

    Again, tid is defined as "lvalue of type TiD constructed from std::forward<Ti>(ti)". This means that the above usage must refer to result_of<TiD cv & (Uj...)> instead. We also have similar defect as in 2017 in regard to the argument types, this leads us to the further corrected form result_of<TiD cv & (Uj&&...)>. This is not the end: Since the Vi are similar sensitive to the argument problem, the last part must say:

    "[..] its type Vi is result_of<TiD cv & (Uj&&...)>::type &&"

    (The bound arguments Vi can never be void types, therefore we don't need to use the more defensive std::add_rvalue_reference type trait)

  3. The function template async is declared as follows (the other overload has the same problem):

    template <class F, class... Args>
    future<typename result_of<F(Args...)>::type>
    async(F&& f, Args&&... args);
    

    This usage has the some same problems as we have found in reference_wrapper (2017) and more: According to the specification in [futures.async] the effective result type is that of the call of

    INVOKE(decay_copy(std::forward<F>(f)), decay_copy(std::forward<Args>(args))...)
    

    First, decay_copy potentially modifies the effective types to decay<F>::type and decay<Args>::type.... Second, the current specification is not really clear, what the value category of callable type or the arguments shall be: According to the second bullet of [futures.async] p. 3:

    Invocation of the deferred function evaluates INVOKE(g, xyz) where g is the stored value of decay_copy(std::forward<F>(f)) and xyz is the stored copy of decay_copy(std::forward<Args>(args))....

    This seems to imply that lvalues are provided in contrast to the direct call expression of [futures.async] p. 2 which implies rvalues instead. The specification needs to be clarified.