You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
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.The text was updated successfully, but these errors were encountered: