Update function objects section to the new format

[Pennycook]

Also fixes a bug in the return type of logical_and and logical_or. Closes #646.

The return types of the void specializations of maximum and minimum may require further discussion. Prior to this change, the specification didn't say exactly which operator(s) would be used to determine ordering, and so I tried to honor that in this new wording.

When we introduced the prior wording there was some discussion of trying to align with std::min and std::max (see #285 (comment)). It we want to describe the behavior in terms of equivalent statements, I think the fix is to say:

• minimum and maximum require T to be LessThanComparable.
• minimum returns (b < a) ? b : a.
• maximum returns (a < b) ? b : a.

[Pennycook]

In the WG meeting today we decided that we should define the return types of the minimum and maximum operators. Because the decltype() only describes the return type of the operator, it doesn't actually constrain the implementation of the operator (i.e., it doesn't force an implementation to use a ternary). I'll make this change soon.

[Pennycook]

This should be read to review, now. Note that the Cpp17LessThanComparable requirement is a precondition and not a constraint. This was surprising to me, but I wanted to follow the ISO C++ definition: https://eel.is/c++draft/alg.min.max

[TApplencourt]

Good catch!

[TApplencourt]

Not in the PR, but if you don't mind to a sneaky update (don't tell our editor :p ) :

float cospi(float x)                (1)
double cospi(double x)              (2)
half cospi(half x)                  (3)

template<typename NonScalar>         (4)
/*return-type*/ cospi(NonScalar x)

This guy (4) is not aligned.

[keryell]

Is there a motivation to have the std::forward in the non-evaluated context?
Actually a maniac programmer could define + with an l-reference to do division and a + with an r-reference to do a multiplication?

[Pennycook]

I don't know the motivation, but this is the way that the return type is declared for the equivalent function objects in in ISO C+ (e.g., https://eel.is/c++draft/function.objects#arithmetic.operations.plus-2).

I think you're right, though -- if std::forward<T>(t) + std::forward<U>(u) is the statement that the operator will run, it's safer to include the std::forward in the decltype just in case somebody does something really weird.