[class.access.base] Are friends defined in-class "in" the class for purposes of access control? CWG1699
Nobody has claimed this yet.
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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