std::forward vs. static_cast

[gatchamix]

When I originally submitted this PR #11 , I had used static_cast instead of std::forward wherever possible.
Aside from consistency (which is absolutely important!) was there any reason for the change?

I bring this up in discussion rather than on the PR itself because I think it’s worth discussing the value of std::forward in general.

Due to its implementation, it creates an overload set, instantiates a function, and performs parameter based overload selection. This has a pretty significant cost for compile-time programs, especially when you’re calling the function on an arbitrarily large variadic pack.

Some research into the costs of std::forward was done by Louis Dionne a few years back, which subsequently led to the rewriting of boost::hana to replace all instances of std::forward with static_cast (boostorg/hana@540f665) - this single change resulted in a 14% compilation speed up!!

Another benefit that’s not mentioned, is when compiling without optimisations or without inlining, this also leads to a smaller binary size - as the explicit std::forward instantiations don’t need to be created and stored within the binary.

I made a small proof-of-concept godbolt to demonstrate that this reduction in binary size applies to tuplet too (at least throughout the tuple_cat demonstration) [insert link here when I’m at a computer]

Did you know about this scenario already? And if so, is there a reason for using std::forward over static_cast?

[gatchamix]

lol, ok disregard this - apparently you swapped everything from std::forward to static_cast while I was asleep 😂

[codeinred]

I did, yeah 😂

When I was looking at the assembly for clang, and I noticed that sometimes std::forward wasn't being optimized out, so I ended up replacing every single instance of std::forward with static_cast. This resulted in better assembly in worst-case scenarios and when optimization isn't turned on.

I didn't know there'd been prior research into this, but it's really interesting, especially to see a 14% compilation speedup from that change alone!

I also looked at the implementation for std::forward, and it appears gcc has a static_assert that should always be true. This may explain part of why std::forward results in a bit of a compilation slowdown.

Edit: here's the code snippet in GCC

  /**
   *  @brief  Forward an rvalue.
   *  @return The parameter cast to the specified type.
   *
   *  This function is used to implement "perfect forwarding".
   */
  template<typename _Tp>
    _GLIBCXX_NODISCARD
    constexpr _Tp&&
    forward(typename std::remove_reference<_Tp>::type&& __t) noexcept
    {
      static_assert(!std::is_lvalue_reference<_Tp>::value, "template argument"
		    " substituting _Tp must not be an lvalue reference type");
      return static_cast<_Tp&&>(__t);
    }