[cmath.syn] LWG 2847: C functions show five overloads; those from [sf.math] only three

[jensmaurer]

The synopsis for <cmath> shows five overloads for "traditional" C math functions, e.g.

• float sin(float);
• double sin(double);
• long double sin(long double);
• float sinf(float);
• long double sinl(long double);

In contrast, for the mathematical special functions described in [sf.math], the synopsis (and the descriptions in [sf.math]) only show three overloads:

• double beta(double);
• float betaf(float);
• long double betal(long double);

This is inconsistent.

In [cmath.syn] p2, we have the "sufficient additional overloads" provision. (As a side note, the provision doesn't talk about adjusting the return type, which seems an oversight.) This provision requires overloads for sin(float) and sin(double). Next, at least one additional overload (possibly a template) is required to handle integer types (and convert them to double), since [conv.fpint] and [over.ics.rank] do not differentiate a conversion from int to float vs. a conversion from int to double, thereby making overload resolution for integer arguments ambiguous.

(Source: Dawn's list of issues discovered during review/integration of the math special functions.)

[jensmaurer]

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.

[tkoeppe]

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.

[jensmaurer]

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

[jensmaurer]

@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
}

[jensmaurer]

@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.)

[tkoeppe]

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

[jensmaurer]

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

[tkoeppe]

@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.

[tkoeppe]

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

[tkoeppe]

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."

[jensmaurer]

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

[tkoeppe]

@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.

[jensmaurer]

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.

[jensmaurer]

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.