This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112e. See for the official list.


1873. Protected member access from derived class friends

Section: 11.8.3  [class.access.base]     Status: CD4     Submitter: Richard Smith     Date: 2014-02-18

[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

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