std conforming extensionsSection: 16.4.6 [conforming] Status: NAD Submitter: Chandler Carruth Opened: 2014-03-22 Last modified: 2015-05-22
Priority: 3
View all other issues in [conforming].
View all issues with NAD status.
Discussion:
Technically, right now, it is not a conforming extension to add a new function to namespace std. Doing so could cause
unqualified lookup on the name of that function in the presence of a using directive to find a different function. This seems
an unreasonable restriction on library vendors providing conforming extensions, as such a using directive seems inherently risky
in unqualified name lookup.
16.4.6.5 [member.functions] implies that adding overloads to a method is a conforming extension, and within some limits the same is true for global functions due to 16.4.6.4 [global.functions].
It would likely be useful to specify that other new entities are valid conforming extensions, or preclude them where they pose serious compatibility problems.[Lenexa 2015-05-06: Move to NAD]
JY: It's a design question, move to LEWG?
AM: NAD: extensions led to us being unable to use the names hash_map, leading to unordered_map etc. Will result in collisions between members.
MC: Agrees, implementations that extend std:: must use __ugly_names for this reason.
JY: I would not oppose NAD.
Move to NAD, consensus.
Proposed resolution: