Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
xmh0511 opened this issue Jun 4, 2021 · 10 comments
Labels
cwg Issue must be reviewed by CWG.

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Jun 4, 2021

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.

@jwakely
Copy link
Member

jwakely commented Jun 4, 2021

I don't think "a direct member or a direct friend" is the correct parse, I think it's "a direct member or a friend".

@jensmaurer jensmaurer changed the title The border-line of the ability of the wording "in" in the rule for defining accessible for members in [class.access.base] [class.access.base] Are friends defined in-class "in" the class for purposes of access control? Jun 4, 2021
@jensmaurer
Copy link
Member

@jensmaurer jensmaurer added the cwg Issue must be reviewed by CWG. label Jun 4, 2021
@xmh0511
Copy link
Contributor Author

xmh0511 commented Jun 4, 2021

I don't think "a direct member or a direct friend" is the correct parse, I think it's "a direct member or a friend".

I'm a proponent of reading it as "a direct member or a direct friend". But I think which reading is not significant for this case here. The core issue is on how many levels will the wording "in" apply to the "friend". Even if we read the sentence your way, it seems there's no effect to this issue.

@jwakely
Copy link
Member

jwakely commented Jun 4, 2021

I agree it doesn't affect this issue, but "direct member" and "direct base class" is used widely. "Direct friend" is never used, and I don't know what it means. What is an indirect friend?

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jun 4, 2021

I agree it doesn't affect this issue, but "direct member" and "direct base class" is used widely. "Direct friend" is never used, and I don't know what it means. What is an indirect friend?

I can absolutely admit your interpretation. However, The reason why I read it as "direct friend" is I suppose the intent of that rule actually wants to make that rule not transitive, hence it might use "direct friend of class N". In addition, from the perspective of English grammar, if its utterance was "a friend", it shouldn't there is no wording "a" between "or" and "friend"; Otherwise, we will think "member" and "friend" share the "direct". It's my opinion.

@jwakely
Copy link
Member

jwakely commented Jun 4, 2021

Otherwise, we will think "member" and "friend" share the "direct".

That's one interpretation, certainly. My point is that the current phrasing is ambiguous.

I think it should either be written as either "a direct member or a direct friend" or "a direct member or a friend". That would avoid the ambiguity.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jun 4, 2021

Otherwise, we will think "member" and "friend" share the "direct".

That's one interpretation, certainly. My point is that the current phrasing is ambiguous.

I think it should either be written as either "a direct member or a direct friend" or "a direct member or a friend". That would avoid the ambiguity.

Violent agree. BTW, there are many similar manner of this use elsewhere in the standard. Most of these ambiguous can be eliminated by the context but some cannot. Even if these ambigous can be eliminated, but they are hard to read. I think these issues should be improved. I would issue them in the later.

@RealLitb
Copy link

RealLitb commented Jun 4, 2021

A member of a class can also access all the members to which the class has access.

This is most probably wrong. Members of base classes become also members of derived classes.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jun 4, 2021

A member of a class can also access all the members to which the class has access.

This is most probably wrong. Members of base classes become also members of derived classes.

Yes, that's another issue. we should say "direct member" for that.

@jensmaurer jensmaurer changed the title [class.access.base] Are friends defined in-class "in" the class for purposes of access control? [class.access.base] Are friends defined in-class "in" the class for purposes of access control? CWG1699 Jun 4, 2021
@jensmaurer
Copy link
Member

This is CWG1699.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG.
Projects
None yet
Development

No branches or pull requests

4 participants