3484. Should <stddef.h> declare ::nullptr_t?

Section: 17.14.7 [support.c.headers.other] Status: New Submitter: Thomas Köppe Opened: 2020-09-06 Last modified: 2022-09-18

Priority: 3

View other active issues in [support.c.headers.other].

View all other issues in [support.c.headers.other].

View all issues with New status.

Discussion:

From this editorial issue request:

The header <stddef.h> is currently specified in 17.14.7 [support.c.headers.other] to not declare a global name corresponding to std::byte, but no similar exclusion exists for std::nullptr_t.

Is an oversight or intentional? There does not seem to be an interoperability reason to provide a global namespace name ::nullptr_t, since this construction would be meaningless in C and thus the name would not be encountered in code that is both valid C and C++.

For lack of justification, I would like to propose to require normatively that no name ::nullptr_t be declared by <stddef.h>.

Additional notes: The proposing paper N2431 mentions only an addition of "nullptr_t" to <cstddef> and does not discuss the impact on <stddef.h>. By omission this means the default rules for <stddef.h> apply and the global name should exist, but this does not provide us with a positive signal of intention.

I also realize that this is a rather obscure point, and that vendors are already shipping ::nullptr_t, so I am also happy to drop this issue as not being worth the churn and the increase in implementation complexity (since removals don't generally simplify implementations). I would welcome a bit of discussion, though.

[2020-09-29; Priority to P3 after reflector discussions]

[2022-09-18; Daniel comments]

See also 3782, which points out that nullptr_t has become a part of the C standard library as of C23 (see WG14-N3042 and WG14-N3048).

Proposed resolution:

This wording is relative to N4910.

1. Modify 17.14.7 [support.c.headers.other] as indicated:

   -1- Every C header other than <complex.h> (17.14.2 [complex.h.syn]), <iso646.h> (17.14.3 [iso646.h.syn]), <stdalign.h> (17.14.4 [stdalign.h.syn]), <stdatomic.h> (32.5.12 [stdatomic.h.syn]), <stdbool.h> (17.14.5 [stdbool.h.syn]), and <tgmath.h> (17.14.6 [tgmath.h.syn]), each of which has a name of the form <name.h>, behaves as if each name placed in the standard library namespace by the corresponding <cname> header is placed within the global namespace scope, except for the functions described in 29.7.6 [sf.cmath], the declaration of std::byte and std::nullptr_t (17.2.1 [cstddef.syn]), and the functions and function templates described in 17.2.5 [support.types.byteops]. It is unspecified whether these names are first declared or defined within namespace scope (6.4.6 [basic.scope.namespace]) of the namespace std and are then injected into the global namespace scope by explicit using-declarations (9.9 [namespace.udecl]).

2. In [diff.cpp??] [Editorial note: new compatibility section to be created for C++20], add a new entry:

   Affected subclause: 17.14.7 [support.c.headers.other]
   Change: Removal of name ::nullptr_t from header <stddef.h>.
   Rationale: std::nullptr_t is a C++-only feature that is not useful for interoperability with ISO C.
   Effect on original feature: Valid C++20 code may fail to compile in this International Standard. Occurrences of #include <stddef.h> and nullptr_t should be replaced with #include <cstddef> and std::nullptr_t.