This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 2373. Make new entities and names in namespace `std` conforming extensions

Section: 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: