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

DR: 18.11.4.7/13.2: get_accessible_base_classes and friends merely of the base class #80

Open
hubert-reinterpretcast opened this issue Sep 23, 2019 · 1 comment

Comments

@hubert-reinterpretcast
Copy link

The definition of get_accessible_base_classes has a weird definition that may be rather unnatural for implementations. In particular, when called in friend of a base class of the class reflected upon by the argument, get_accessible_base_classes will consider that base class accessible.

@Axel-Naumann
Copy link
Contributor

Axel-Naumann commented Feb 13, 2020

That's a design issue; the wording and the intent are actually compatible. But if I understand Hubert's point correctly then that's indeed not what the operation should be doing, though for me the motivation isn't the difficulty for implementers but the fact that accessibility should be determined purely by looking at where get_accessible_base_classes is invoked in the inheritance hierarchy. Example:

class A{};
class B: protected A{
  friend class C;
};
class C {
  using bases =  get_accessible_base_classes_t<reflexpr(B)>; // 1
};
class D: public B {
  using bases =  get_accessible_base_classes_t<reflexpr(B)>; // 2
};

2 should be non-empty and is non-empty in the current wording. 1 should be empty but is non-empty in the current wording. I suggest to leave this as an issue and resolve post publication.

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