My opinion: Since we do not (and should not) show the exact overload set needed to satisfy all of the "sufficient additional overloads" provision, we might as well get rid of the float and long double overloads for the traditional C library functions. There's no point in a halfway approach.

Hm, we discussed this in Oulu a bit. We definitely wanted the floating overloads, together with the comment, so that it's easy to see what's added relative to C (e.g. because those functions might need to have different linkage). I think the floating overloads are specified to exist exactly in this form. By contrast, we didn't want to add the "sufficient" overloads because their exact shape is not specified.

(I think you would generally just provide an intmax_t version to handle all integral arguments.)

So I am mildly in favour of adding the float and long double overloads do the special functions, too.

@jwakely felt pretty strongly about this issue if I recall correctly.

@W-E-Brown: What's your opinion?

@tkoeppe: "I think you would generally just provide an intmax_t version to handle all integral arguments."

This statement appears to be incorrect. "integral conversion" and "floating-integral conversion" have the same rank in [over.ics.scs].

void f(float);
void f(double);
void f(long long int);

void g()
{
f(1); // ambiguous
}

@tkoeppe: "I think the floating overloads are specified to exist exactly in this form."
Other than the synopsis, I can't find such a requirement. Also, the "effectively cast" provision could be satisfied by an enable_if template, calling the double version for float and long double operands after casting. (After all, precision and accuracy are unspecified anyway.)

Ah yes, indeed. Interesting. Well, I'd like @jwakely to weigh in, who had asked for the current style.

Put differently, is there an intended normative difference in overloading behavior between, say, sin and beta? If not, we should not have different presentations.

@jensmaurer: Ah, wait, it was like this: The overloads were specified in the wording before we applied P0175. So that's pre-Oulu. The synopses replace that wording.

@jensmaurer: That's 26.9p11 and p12 in, say N4594. Note that p13 adds the additional overloads.

I wonder whether there's some wording missing, both before and after P0175, that the float and long double overloads actually call the corresponding implementation: foo(float) calls foof, and foo(long double) calls fool.

I always assumed that that would be the intention, but I think the wording never made this precise. I think that would be the real value of listing those overloads in the synopsis. "You can use the name foo, but you'll get the appropriate implementation for your use case."

@tkoeppe: Aha. That makes sense, but such desires are missing from the normative wording.

@jensmaurer: Yes, I think we should probably make an LWG issue and request that a paragraph be added that says that the float/long double overloads behave like the f/l functions.

Subject: New LWG issue: sin(float) should call sinf(float)
To: Marshall Clow lwgchair@gmail.com

With P0175R1, we now show in [cmath.syn] three overloads for
the "sin" function: One taking a float, one taking a double,
and one taking a long double. However, there is no statement
that sin(long double) should actually invoke sinl, presumably
delivering extra precision.

An implementation like

inline long double sin(long double x)
{ return sinf(x); }

seems to satisfy the "effectively cast" requirement,
but is certainly unintentional.

The same issue arises for all math functions inherited from C.

See LWG issue 2847.

Keeping this editorial issue open to address the original question of "5 vs. 3 overloads shown in the synopsis" after LWG has resolved the issue.

See also https://cplusplus.github.io/LWG/issue3234

Verbose overloads are removed with P1467.

The original concern (LWG3234) is resolved by P1467R9 (#5670).