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] p5 Whether the base-specifier-list of a derived class is a point R where protected member is accessible? CWG372 #5404

Open
xmh0511 opened this issue Apr 20, 2022 · 5 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Apr 20, 2022

We define whether a member of naming class N is accessible at R is as the following:

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

  • [...]
  • m as a member of N is protected, ..., or in a member of a class P derived from N, where m as a member of P is public, private, or protected, or

It does not mention the base-specifier-list of class P. Consider this example:

struct N{
 protected:
    struct Base{};
};
struct P: N::Base, N{};

member Base is named in class N and N is a base class of class P. However, as defined above, we just say Base is accessible in the member of P. We do not explicitly say that Base is accessible at R that occurs in base-specifier-list of P. Although, we mention it in [class.access.general] p1

A member of a class can be

  • [...]
  • protected, that is, it can be named only by members and friends of the class in which it is declared, by classes derived from that class, and by their friends (see [class.protected]); or

However, 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

The interpretation of a given construct is established without regard to access control. If the interpretation established makes use of inaccessible members or base classes, the construct is ill-formed.

We can see that implementations have a divergence interpretation to this example.

@jensmaurer
Copy link
Member

jensmaurer commented Apr 20, 2022

This is CWG372, although the specific wording bug you found doesn't seem to be addressed in the proposed resolution.

@jensmaurer jensmaurer changed the title [class.access.base] p5 Whether the base-specifier-list of a derived class is a point R where protected member is accessible? [class.access.base] p5 Whether the base-specifier-list of a derived class is a point R where protected member is accessible? CWG372 Apr 20, 2022
@jensmaurer
Copy link
Member

This is the example in 11.8.1 p7 struct D: A::B, A { };

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 21, 2022

This is the example in 11.8.1 p7 struct D: A::B, A { };

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 R occurs in base-specifier-list of class P.

template<class T>
struct E: T::Base, T{};
E<N> e;

T::Base is a dependent name, which should be checked in the instantiation context, we have no base-specifier-list on grammar at that context.

@jensmaurer
Copy link
Member

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.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 21, 2022

but need to await instantiation for the rule to make sense.

The concern is that, in the implicit instantiation of E<N>, we do not have grammar stuff that looks like

struct E<N>: N::Base, N{};

Where the stuff N::Base, N that follows : is the actual syntactically base-specifier-list(on grammar). This is similar to that: the implicit function call does not have a postfix-expression, as discussed in #4561 (comment). We have no way to express the grammar that would appear in the instantiation stuff since there is no corresponding explicit source code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants