Skip to content

DR: 18.11.4.7: get_accessible_* and the name used for the access #79

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.

Sign up for GitHub

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

Jump to bottom
Open
hubert-reinterpretcast opened this issue Sep 23, 2019 · 5 comments
Open

DR: 18.11.4.7: get_accessible_* and the name used for the access #79

hubert-reinterpretcast opened this issue Sep 23, 2019 · 5 comments

Comments

@hubert-reinterpretcast
Copy link

hubert-reinterpretcast commented Sep 23, 2019 •
edited
Loading

The accessibility of f below from C depends upon the name used to name A. It is unclear what the application of get_accessible_member_functions upon the meta-object types produced in g() and h() h2() would generate.

struct A { static int f(); };
class B : A {};
class C : B {
  static auto *g() { return static_cast<reflexpr(::A) *>(0); }
  static auto *h() { return static_cast<reflexpr(A) *>(0); }
  static auto *h2() { return static_cast<
      get_class_t<get_element_t<0, get_base_classes_t<reflexpr(C)>>> *>(0); }
};
@hubert-reinterpretcast
Copy link
Author

hubert-reinterpretcast commented Sep 23, 2019 •
edited
Loading

Ditto get_accessible_member_types, etc.

@hubert-reinterpretcast
Copy link
Author

The injected-class-name for A is private to B from C, so the h() case is invalid.

@hubert-reinterpretcast
Copy link
Author

More of a note-to-self: using-declarations can also change access.

@hubert-reinterpretcast
Copy link
Author

I think this issue is not at all straightforward. Protected non-static members are also complicated.

@Axel-Naumann
Copy link
Contributor

IMO that's a design issue out of scope for the wording review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Axel-Naumann @hubert-reinterpretcast