cplusplus / cplusplus/draft

[class.access.base] Are friends defined in-class "in" the class for purposes of access control? CWG1699

Open
#4,627 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cwg
Dominant language
TeX
Stars
221
Forks
813
Avg merge
16h 4m
Merged PRs (30d)
36

Description

A member m is accessible at the point R when named in class N if

  • m as a member of N is private, and R occurs in a direct member or friend of class N

Please see this example:

class A{
    int v;
    friend class B;
};
class B{
    friend void fun(A& t){
        t.v = 0;  // R occurs here
    }
};

Clang accepts this code while GCC rejects it. According to the above rule, It appears to me that R indeed occurs in the direct friend of class A, where A is the naming class and the direct friend of A is class B. So, Is that the meaning of "in" interpreted by Clang be the original intent of the standard? I suppose it's not true. Meanwhile, the example given in [class.friend#10] is a bit different from this example since R does not occur in the direct friend of the granting friendship class.

There's no rule elsewhere in the standard that restricts the border-line that R occurs in a friend class would be. Conversely, there's still no rule in the standard guarantees that this example is definitely ill-formed, in the same way as these rules:

A member of a class can also access all the members to which the class has access. A local class of a member function may access the same members that the member function itself may access.

Declaring a class to be a friend implies that private and protected members of the class granting friendship can be named in the base-specifiers and member declarations of the befriended class.

Since a friend declaration of a class does not introduce a new member for that class, fun is not a member of class B, The above rules are not suitable here.
So, I think this case is in an underspecified situation, which might be the reason why GCC and Clang have quite different interpretations for this example. I mean the standard does not explicitly say "no" to the overread of the wording "in" of Clang.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with [class.access.base] and [class.friend#10], then compare the linked Compiler Explorer example under GCC and Clang. Determine whether “in a direct member or friend” includes the friend definition shown and record the intended resolution for CWG1699.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.