Forward without forward

Contents

• Motivation
• Proposal
• Revision History

Motivation

template <class X, class Y>
decltype(auto) foo(X&& x, Y&& y) {
    return std::forward<X>(x)(std::forward<Y>(y));
}

// C++17
auto bar = [](auto&& x, auto&& y) {
    return std::forward<decltype(x)>(x)(std::forward<decltype(y)>(y));
};

// C++2a
auto bar = []<class X, class Y>(X&& x, Y&& y) {
    return std::forward<X>(x)(std::forward<Y>(y));
};

#define FWD(x) std::forward<decltype(x)>(x)

template <class X, class Y>
decltype(auto) foo(X&& x, Y&& y) {
    return FWD(x)(FWD(y));
}

auto bar = [](auto&& x, auto&& y) {
    return FWD(x)(FWD(y));
};

A search on GitHub shows over 100 such definitions. That is substantially clearer, but are we really going to suggest that people use a macro?! Let's not. Forwarding references even got their name from the fact that they are intended to be std::forward()-ed, so it's awkward when the expected and typical usage is just so very verbose. The body of the lambda with std::forward is 73 characters, the body with FWD is 23. It is the contention of this proposal that those extra characters harm readability and don't help anybody.

Code that forwards is just so much more verbose than code that doesn't. But forwarding in itself doesn't justify the verbosity or resulting complexity. Unlike std::move and std::ref which are used to do non-typical things and deserve to be visible markers for code readability and understanding, std::forward is much more typical in these contexts and does not need as much of a sign post. We can do better.

Proposal

This paper would like to see a shorter way to forward arguments and proposes non-overloadable unary operator>>, where >>expr is defined as static_cast<decltype(expr)&&>(expr). This addition would make it easier to write and, more importantly, read code that uses forwarding.

Note that >>x, where x is not an lvalue reference, is also equivalent to std::move(x).

Examples demonstrating the improvement:

C++17	This proposal
template <class X, class Y> decltype(auto) foo(X&& x, Y&& y) { return std::forward<X>(x)(std::forward<Y>(y)); } auto bar = [](auto&& x, auto&& y) { return std::forward<decltype(x)>(x)(std::forward<decltype(y)>(y)); };	template <class X, class Y> decltype(auto) foo(X&& x, Y&& y) { return (>>x)(>>y); } auto bar = [](auto&& x, auto&& y) { return (>>x)(>>y); };
Implementing std::apply (code from cppreference)
namespace detail { template <class F, class Tuple, std::size_t... I> constexpr decltype(auto) apply_impl(F&& f, Tuple&& t, std::index_sequence<I...>) { return std::invoke(std::forward<F>(f), std::get<I>(std::forward<Tuple>(t))...); } } // namespace detail template <class F, class Tuple> constexpr decltype(auto) apply(F&& f, Tuple&& t) { return detail::apply_impl( std::forward<F>(f), std::forward<Tuple>(t), std::make_index_sequence< std::tuple_size_v<std::decay_t<Tuple>>>{}); }	namespace detail { template <class F, class Tuple, std::size_t... I> constexpr decltype(auto) apply_impl(F&& f, Tuple&& t, std::index_sequence<I...>) { return std::invoke(>>f, std::get<I>(>>t)...); } } // namespace detail template <class F, class Tuple> constexpr decltype(auto) apply(F&& f, Tuple&& t) { return detail::apply_impl( >>f, >>t, std::make_index_sequence< std::tuple_size_v<std::decay_t<Tuple>>>{}); }
Delaying invocation (assuming pack expansion in init-capture - P0780)
template <class F, class... Args> auto delay_invoke(F&& f, Args&&... args) { return [f=std::forward<F>(f), args=std::forward<Args>(args)...)]() -> decltype(auto) { return std::invoke(f, args...); }; }	template <class F, class... Args> auto delay_invoke(F&& f, Args&&... args) { return [f=>>f, args=>>args...]() -> decltype(auto) { return std::invoke(f, args...); }; }
Overload set as function object (assuming abbreviated lambda - P0573)
[](auto&&... args) => f(std::forward<decltype(args)>(args)...) [&](args...) => obj.bar(std::forward<decltype(args)>(args)...)	[](auto&&... args) => f(>>args...) [&](args...) => obj.bar(>>args...)

This proposal does not suggest deprecating std::forward(). There is nothing actually wrong with using it, and moreover there is another functionality of this function template that is quite important: forwarding expressions to a different type. This isn't common, but is more important to highlight as different from simple forwarding. This extension allows for making simple forwarding look simple, while making complex forwarding look complex.

Unary >> is ill-formed today so this is purely a language extension.

Impact on Compile Times

There are two ways that you can forward a variable: you can use std::forward or you can use static_cast directly (as this proposal's forwarding operator does):

template <class X, class Y>
decltype(auto) foo(X&& x, Y&& y) {
    return std::forward<X>(x)(std::forward<Y>(y));    // with std::forward
    return static_cast<X&&>(x)(static_cast<Y&&>(y));  // with static_cast, exactly equivalent
}

Implementation Experience

Revision History