Just general concerns with this paper: it's adding something to <cmath>, but it doesn't update any of the wording that things in cmath are also in math.h. E.g. [cmath.syn]p1 probably needs updating? And p2 talks about general additional overloads; does this apply to lerp, too?

Just general concerns with this paper: it's adding something to <cmath>, but it doesn't update any of the wording that things in cmath are also in math.h. E.g. [cmath.syn]p1 probably needs updating?

This came up in LWG. I may have volunteered to submit an editorial issue to reword [cmath.syn]/1 (I don't precisely recall, and in any case I obviously failed to do so). It's silly for us to say that <cmath> and math.h are the same except for [list of items that we must remember to modify whenever we add something to <cmath>]. Something like:

Much of the header \tcode{<cmath>} is the same as the C standard library header \tcode{<math.h>}.
The entities and macros declared in \tcode{cmath} that are not specified in this 
subclause~\ref{c.math} have the same behavior as in the C standard library\iref{library.c}. 
\begin{note}
Several functions have additional overloads in this document not present in \tcode{<math.h>}, 
but they have the same behavior as in the C standard library.
\end{note}

would be an improvement. (Personally, I'd prefer that we put our additions in <math> instead of <cmath> and stop messing with C's headers, but that bridge was burned long ago.)

And p2 talks about general additional overloads; does this apply to lerp, too?

This also came up in LWG, we were satisfied to apply [cmath.syn]/2 to lerp.

And p2 talks about general additional overloads; does this apply to lerp, too?

This also came up in LWG, we were satisfied to apply [cmath.syn]/2 to lerp.

Thanks a lot. I wish authors would update their final paper to include decisions like that; it seems like a shame that all this information that had to be discovered will get lost in time.