On Jul 8, 2016, at 12:54 AM, Vicente J. Botet Escriba wrote:

Le 02/07/2016 à 19:53, Paul Fultz II a écrit :

...

...

On Jul 2, 2016, at 3:03 AM, Vicente J. Botet Escriba 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, Have these bugs been fixed?

Gcc 4.6 is not fixing any new bugs. And MSVC still has some bugs, I haven’t tested it with latest Update 3 to see.

...

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. What do you mean by properly constrained?

That is you constraint the function based on its type requirements.

...

All the functions in the Fit library are SFINAE-friendly, which help preserve the constraints of functions after being adapted. Could you elaborate with some examples?

Yes, take these functions: FIT_STATIC_LAMBDA_FUNCTION(fn) = [](auto x, auto y) FIT_RETURNS(x.foo(), y.bar()); FIT_STATIC_LAMBDA_FUNCTION(flipped_fn) = flip(fn); So, `is_callable()` is only true for types T that have `.foo()` member function and types U that have a `.bar()` member function. Accordingly, `is_callable()` is only true for types T that have `.bar()` member function and types U that have a `.foo()` member function due to the flipped parameters, but all the constraints of the original function has been preserved.

...

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.

Is this something the compiler must fix? http://lists.llvm.org/pipermail/llvm-bugs/2012-July/024138.html

No, as mentioned by Eli Friedman: noexcept clauses don't get instantiated until we instantiate the defintion; see [temp.deduct]p7.

Could you tell me more about how would you avoid the substitution failure inside noexcept?

By making sure substitution failure happens before noexcept is instantiated. Exactly how that is necessary, I will need to look into.

Thanks, Vicente

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Le 04/07/2016 à 23:10, Louis Dionne a écrit :

Vicente J. Botet Escriba writes:

...

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. The usual rule that's valid across Hana is that whenever the inputs are constexpr, the outputs are constexpr too. Hence, when you use `hana::overload` with constexpr functions, the result will be constexpr. And if these functions can be called in a constant expression, then so does the resulting `hana::overload`.

There is no problem for function objects. Louis, I don't remember, does Hana overload accepts pointer to member or non-member functions? Vicente