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
Comments
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. |
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. |
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. |
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. |
This is CWG1699. |
Please see this example:
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 classB
. 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 sinceR
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:
Since a friend declaration of a class does not introduce a new member for that class,
fun
is not a member of classB
, 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.
The text was updated successfully, but these errors were encountered: