Re: [boost] [Hana/Fit] about constexpr/noexcept on equivalent functions to std::overload

Subject: Re: [boost] [Hana/Fit] about constexpr/noexcept on equivalent functions to std::overload
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-07-02 13:53:14

> On Jul 2, 2016, at 3:03 AM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:
> 
> Hi,
> 
> 
> On the C++ standard meating in Oulu, we decided to make the std::overload function constexpr and conditionaly noexcept and ensure that the overloaded functions shall be constexpr if the stored finctions are.
> 
> I don't find in the reference documentation of Hana and Fit any reference of whether the overloaded functions preserve constexpr or not.
> 
> There is a reedit post [1] and CWG issue 1581 [2] that are related.
> 
> Could the authors clarify?

The Fit library preserves constexpr both for initialization of the function and the evaluation of the function. However, the evaluation of constexpr functions are somewhat limited on gcc 4.6 and MSVC due to bugs in their implementations, however, constexpr initialization is supported. This is described here in the documentation:

http://fit.readthedocs.io/en/latest/doc/src/index.html#contexpr-support

Note, constexpr does make the instantiations of templates more aggressive since it will instantiate the body of the constexpr function, however, this is not a problem if the function is properly constrained. All the functions in the Fit library are SFINAE-friendly, which help preserve the constraints of functions after being adapted. 

Constexpr does become an issue for the fix-point combinator because it won’t stop instantiating due to recursion. Instead, the Fit library has a depth it uses to stop the constexpr instantiation. That is, the overloads are declared constexpr up to a certain depth and then switches to overloads that are not constexpr. This depth can be set by FIT_RECURSIVE_CONSTEXPR_DEPTH macro(defaults to 16), see here:

http://fit.readthedocs.io/en/latest/include/fit/fix.html 

There is no support for noexcept currently in the Fit library. I have thought about adding support for it at some point. I have heard for some people that it wasn’t necessary. The difficult problem with noexcept is that it doesn’t take part in the substitution failure, so some care needs to be taken that substitution failure happens before the noexcept clause is evaluated. Since the committee is adding noexcept to adaptors such as `std::overload`, I think it would be good idea to add that to the Fit library as well.

Paul