Created on 2020-09-06.00:00:00 last changed 1 week ago
This wording is relative to N4861.
Modify [depr.c.headers.other] as indicated:
-1- Every C header other than <complex.h> ([depr.complex.h.syn]), <iso646.h> ([depr.iso646.h.syn]), <stdalign.h> ([depr.stdalign.h.syn]), <stdbool.h> ([depr.stdbool.h.syn]), and <tgmath.h> ([depr.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 [sf.cmath], the declaration of std::byte ([cstddef.syn]), and the functions and function templates described in [support.types.byteops]. It is unspecified whether these names are first declared or defined within namespace scope ([basic.scope.namespace]) of the namespace std and are then injected into the global namespace scope by explicit using-declarations ([namespace.udecl]).
In [diff.cpp??] [Editorial note: new compatibility section to be created for C++20], add a new entry:
From this editorial issue request:The header <stddef.h> is currently specified in [depr.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-13 14:19:30||admin||set||messages: + msg11481|