This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Moved to DR at the May, 2015 meeting.]
According to 11.8.3 [class.access.base] paragraph 5,
A memberm is accessible at the pointR when named inclassN if
...
m as a member ofN is protected, andR occurs in a member or friend ofclassN, or in a member or friend of a classP derived fromN, wherem as amember ofP is public, private, or protected, or
...
The granting of access via classP is troubling. At theleast, there should be a restriction thatP be visible atR. Alternatively, this portion of the rule could be removedaltogether; this provision does not appear to be widely used inexisting code and such references can be easily converted to useP instead ofN for naming the member.
Notes from the June, 2014 meeting:
CWG noted that removing thefriend provision wouldintroduce an undesirable asymmetry between member functionsofP and its friends. Instead, the intent is to requireP to be a complete type atR.
Notes from the November, 2014 meeting:
Although the asymmetry is unfortunate, the differencebetween a reference in a member function and a reference ina friend is that the member function concretely determineswhichP is in view, while the friend could bebefriended by a class that is a specialization of a classtemplate and thus would require instantiations that wouldnot otherwise occur. CWG thus decided simply to eliminatethe friend case.
Proposed resolution, November, 2014:
Change bullet 5.3 of 11.8.3 [class.access.base] as follows:
...A memberm is accessible at thepointR when named in classN if
...
m as a member ofN is protected,andR occurs in a member or friend ofclassN, or in a member
or friendof aclassP derived fromN, wheremas a member ofP is public, private, or protected,orthere exists...