-
Notifications
You must be signed in to change notification settings - Fork 772
[class.access.base] p5 Whether the base-specifier-list of a derived class is a point R where protected member is accessible? CWG372 #5404
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
Comments
This is CWG372, although the specific wording bug you found doesn't seem to be addressed in the proposed resolution. |
This is the example in 11.8.1 p7 |
Yes, we just lack a wording that can interpret why it's well-formed(currently, it's contradictory with [class.access.general] p5). I think it's hard to simply say that template<class T>
struct E: T::Base, T{};
E<N> e;
|
I think we have plenty of precedence in the standard where we refer to grammar, but need to await instantiation for the rule to make sense. |
The concern is that, in the implicit instantiation of struct E<N>: N::Base, N{}; Where the stuff |
We define whether a member of naming class
N
is accessible at R is as the following:It does not mention the base-specifier-list of class P. Consider this example:
member
Base
is named in classN
andN
is a base class of classP
. However, as defined above, we just sayBase
is accessible in the member ofP
. We do not explicitly say thatBase
is accessible at R that occurs in base-specifier-list ofP
. Although, we mention it in [class.access.general] p1However, it is not the definition of whether the member is accessible. Since we only phrase the following rule based on whether the members or base classes are accessible
We can see that implementations have a divergence interpretation to this example.
The text was updated successfully, but these errors were encountered: