Patch: bug fix for PR18218

[Howard Hinnant]

On Dec 19, 2013, at 6:36 PM, Matt Calabrese <rivorus at gmail.com> wrote:

> Ah, I'm out of my domain, I didn't realize the wording of [c.math] 11
> in addition to [global.functions] was what was causing the need for
> the templates... I think I'm starting to understand the full issues
> here. One solution might be something along these lines:
> 
> 1) Declare the overloads that are explicitly specified. These are just
> 3 overloads total for each IIUC.
> 2) Declare a template overload that takes r-value references for each
> argument that is enabled if and only if the corresponding function
> would be callable with the forwarded arguments (this can be done with
> a metafunction implemented via SFINAE). This function would internally
> cast the arguments to the corresponding type and invoke the actual
> function (therefore it exhibits the same observable behavior as if
> this template didn't exist).
> 3) Declare a second template overload that takes r-value references
> for each argument but that is DISABLED if the corresponding function
> would be callable with the forwarded arguments. This overload would be
> the one that does something along the lines of the trick that was
> originally implemented (though adjusted for r-value refs). It would do
> an is_arithmetic check rather than the __numeric_type trick.
> 
> The overall result would be that anything that would have been
> callable with only the original overloads would still work and have
> the same behavior. The enable_if makes sure that the fallback would be
> used only in the cases where such a call would have failed with only
> the explicitly specified overloads. I think this satisfies all of the
> standard's requirements.

<nod> I've been thinking the same thing since your first reply.  Thanks for bringing this issue up.

Howard