This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-19
[Moved to DR at the May, 2015 meeting.]
According to 11.8.3 [class.access.base] paragraph 5,
A member m is accessible at the point R when named in class N if
...
m as a member of N is protected, and R occurs in a member or friend of class N, or in a member or friend of a class P derived from N, where m as a member of P is public, private, or protected, or
...
The granting of access via class P is troubling. At the least, there should be a restriction that P be visible at R. Alternatively, this portion of the rule could be removed altogether; this provision does not appear to be widely used in existing code and such references can be easily converted to use P instead of N for naming the member.
Notes from the June, 2014 meeting:
CWG noted that removing the friend provision would introduce an undesirable asymmetry between member functions of P and its friends. Instead, the intent is to require P to be a complete type at R.
Notes from the November, 2014 meeting:
Although the asymmetry is unfortunate, the difference between a reference in a member function and a reference in a friend is that the member function concretely determines which P is in view, while the friend could be befriended by a class that is a specialization of a class template and thus would require instantiations that would not otherwise occur. CWG thus decided simply to eliminate the friend case.
Proposed resolution, November, 2014:
Change bullet 5.3 of 11.8.3 [class.access.base] as follows:
...A member m is accessible at the point R when named in class N if
...
m as a member of N is protected, and R occurs in a member or friend of class N, or in a member
or friendof a class P derived from N, where m as a member of P is public, private, or protected, orthere exists...