Add a conditional noexcept specification to std::apply

• • Abstract
  • Discussion
  • Impact on the Standard
  • Implementation experience
  • Proposed change
  • References

Abstract

This paper proposes to add a noexcept-specification to std::apply.

Discussion

With the introduction of the C++23 zip family, apply is making a comeback and appeared in a lot of its function implementations.

For example, in [range.zip.transform.iterator], zip_transform_view::iterator::operator*()'s equivalent Effect is defined as:

  
    return apply([&](const auto&... iters) -> decltype(auto) {
      return invoke(*parent_->fun_, *iters...);
    }, inner_.current_);
    

However, strictly speaking, this operator*() should not be done through apply. The reason is that it still has a noexcept(see below) specification which is equivalent to noexcept(invoke(*parent_­->fun_­, *std​::​get<Is>(inner_­.current_­)...)), where Is is the pack 0, 1, …, (sizeof...(Views)-1). And in view of the fact that standard is very conservative with the noexcept specifications in the library specification, this makes apply lacks the noexcept specification and becomes a non-noexcept function. Fortunately, the standard also defines the semantics of apply in terms of another equivalent-to Effects, this part constitutes the effective noexcept specification of operator*().

But if we look at apply closely, according to its Effects in [tuple.apply]:

  
    template<class F, class Tuple, size_t... I>
    constexpr decltype(auto) apply-impl(F&& f, Tuple&& t, index_sequence<I...>) {
                                                                          // exposition only
      return INVOKE(std::forward<F>(f), get<I>(std::forward<Tuple>(t))...)
    }
    

It just simply uses index_sequence to expand get to extract the elements of tuple and then forward them to INVOKE together with callable. And since get is a noexcept function (except for the subrange-overload, but the standard does not specify whether apply can be applied to subrange) and invoke is conditional noexcept, I think there is no reason not to make apply "transparently" become conditional noexcept.

In my opinion, invoke(f, args...) should be completely equivalent to apply(f, forward_as_tuple(args...)), adding noexcept to apply can easily achieve this and make it more consistent with invoke.

Impact on the Standard

Since it is a pure change for apply, there will be no impact. For the zip family, apply can "indeed" be used for its implementation. This also allows users to freely add noexcept specification to the functions implemented through apply in the future.

Implementation experience

Proposed change

References