P1339 Disallowing the friending of names in namespace std

[jensmaurer]

P1339R0 Disallowing the friending of names in namespace std (CJ Johnson)

[tituswinters]

LEWG in Kona: Assume that users have not given types in namespace std access to non-public members of their types unless otherwise permitted by the standard.

(Change “private” to “non-public”). Forward to LWG to update SD-8. SF F N A SA 8 8 1 0 0

[wg21bot]

P1339R1 Disallowing the friending of names in namespace std (CJ Johnson)

[mclow]

This can be updated post-Cologne; since it doesn't affect the standard directly.

[JeffGarland]

Per chair discussion since this is LEWG policy paper LWG will not review further.

[inbal2l]

Was reviewed on LEWG mailing list. Attaching a summary of the feedback for this proposal:

1. Generally good reaction to the direction (the example of friending "make_shared"was brought up). There was a suggestion of an alternative phrasing: To make friending names in std:: useless by making it clear that any invocation described in a component's effects aren't necessarily done as that component, but may be done by some delegated component.

2. A discussion about SD-8 (https://isocpp.org/std/standing-documents/sd-8-standard-library-compatibility) vs. the standard as the platform:

   For in standard:

   1. SD-8 gives hints how the standard may evolve in future revisions.
   2. Currently the standard "say" (by omission) that befriending std::things has no effect. The text to disallow it needs to be in the standard (Somewhere in [constraints] might be a good spot).
   3. When curious users run into such problems, their more-knowledgeable friends point them to the exact words, both as a quotation and as a chapter & verse reference to the standard. (...)
   4. Sounds like a Note to help make that clearer to non-experts (perhaps indirectly via the usual-suspect books and blogs) would be very helpful, then.

   5. Examples given for existing restrictions: https://eel.is/c++draft/namespace.std#6, https://eel.is/c++draft/algorithms.requirements#15

      For in SD-8:

   6. Given that the status quo is that befriending std:: things has no normative effect, I think SD-8 is fine.
   7. WG21 already effectively communicates to expert implementors that friending things in the STL has no normative effect. The point of CJ's feature request AIUI is to add "friending things in the STL" into the specific document that we maintain for the purpose of telling users "hey, authority says, don't do these things."

3. Discussion regarding whether the result of such use should be UB

   Example by Nevin:

   class A { 
       size_t do_hash() const;
       friend class std::hash<A>;
       template<typename T>
       friend class std::hash;
   };
   
   namespace std {
       template <>
       struct hash<A> {
           size_t operator()(A const& a) const { return a.do_hash(); }
       };
   };

   1. Granting friendship to operations that aren’t part of a class but must have access to private/protected members are common – it’s not the users’ fault our “hashing protocol” is a class that has to be specialized.
   2. We want to say that befriending library entities is UB, but befriending program-defined specializations (or program-defined non-template customization points) is fine, since program-defined entities are the responsibility of the program, as long as they don't otherwise violate their requirements.

To conclude: This topic, as it reveals a major discussion of "indicating the correct usage to users", should be scheduled to an LEWG Telecon.

[brycelelbach]

Deferred to C++26 due to lack of time.

[brycelelbach]

Deferring as we lack a champion for this.

[brycelelbach]

Marking as needs-revision as this is out of date.