323. abs() overloads in different headers

Section: 29.7 [c.math] Status: NAD Submitter: Dave Abrahams Opened: 2001-06-04 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [c.math].

View all issues with NAD status.

Discussion:

Currently the standard mandates the following overloads of abs():

    abs(long), abs(int) in <cstdlib>

    abs(float), abs(double), abs(long double) in <cmath>

    template<class T> T abs(const complex<T>&) in <complex>

    template<class T> valarray<T> abs(const valarray<T>&); in <valarray>

The problem is that having only some overloads visible of a function that works on "implicitly inter-convertible" types is dangerous in practice. The headers that get included at any point in a translation unit can change unpredictably during program development/maintenance. The wrong overload might be unintentionally selected.

Currently, there is nothing that mandates the simultaneous visibility of these overloads. Indeed, some vendors have begun fastidiously reducing dependencies among their (public) headers as a QOI issue: it helps people to write portable code by refusing to compile unless all the correct headers are #included.

The same issue may exist for other functions in the library.

Redmond: PJP reports that C99 adds two new kinds of abs: complex, and int_max_abs.

Related issue: 343.

[ Bellevue: ]

The situation is not sufficiently severe to warrant a change.

Rationale:

The programs that could potentially be broken by this situation are already fragile, and somewhat contrived: For example, a user-defined class that has conversion overloads both to long and to float. If x is a value of such a class, then abs(x) would give the long version if the user included <cstdlib>, the float version if the user included <cmath>, and would be diagnosed as ambiguous at compile time if the user included both headers. The LWG couldn't find an example of a program whose meaning would be changed (as opposed to changing it from well-formed to ill-formed) simply by adding another standard header.

Since the harm seems minimal, and there don't seem to be any simple and noninvasive solutions, this is being closed as NAD. It is marked as "Future" for two reasons. First, it might be useful to define an <all> header that would include all Standard Library headers. Second, we should at least make sure that future library extensions don't make this problem worse.