Repository navigation
[cmath.syn] LWG 2847: C functions show five overloads; those from [sf.math] only three #1247
Description
Activity
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
floatandlong doubleoverloads 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_tversion to handle all integral arguments.)So I am mildly in favour of adding the
floatandlong doubleoverloads 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 thedoubleversion forfloatandlong doubleoperands after casting. (After all, precision and accuracy are unspecified anyway.)Put differently, is there an intended normative difference in overloading behavior between, say,
sinandbeta? 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
floatandlong doubleoverloads actually call the corresponding implementation:foo(float)callsfoof, andfoo(long double)callsfool.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/lfunctions.Subject: New LWG issue: sin(float) should call sinf(float)
To: Marshall Clow lwgchair@gmail.comWith 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.
- changed the title
[-][cmath.syn] C functions show five overloads; those from [sf.math] only three[/-][+][cmath.syn] LWG 2847: C functions show five overloads; those from [sf.math] only three[/+]on Oct 11, 2018 - Reacted by A. Jiang
Verbose overloads are removed with P1467.
The synopsis for
<cmath>shows five overloads for "traditional" C math functions, e.g.In contrast, for the mathematical special functions described in [sf.math], the synopsis (and the descriptions in [sf.math]) only show three overloads:
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)andsin(double). Next, at least one additional overload (possibly a template) is required to handle integer types (and convert them todouble), since [conv.fpint] and [over.ics.rank] do not differentiate a conversion frominttofloatvs. a conversion frominttodouble, thereby making overload resolution for integer arguments ambiguous.(Source: Dawn's list of issues discovered during review/integration of the math special functions.)