Closed xmh0511 closed 1 year ago
I think the phrase "occurs in" should be interpreted lexically and thus shouldn't be affected by instantiation.
I think the phrase "occurs in" should be interpreted lexically and thus shouldn't be affected by instantiation.
In this case, the access checking cannot lexically apply to t.a
since t
has a dependent type, further name lookup will happen in the instantiation context, hence access checking should also happen in that context, which is after name lookup.
What happens for a function template defined inside a class with a dependent parameter possibly taking the class of which the function template is a member? I think the situation is (or should be) exactly the same.
What happens for a function template defined inside a class with a dependent parameter possibly taking the class of which the function template is a member? I think the situation is (or should be) exactly the same.
Because the function template is a member of that class, all of its specializations are members of that class, hence they have permission to access the private member. Instead, lambda-expression is not a member of that class. Furthermore, consider this example:
template<class T>
class B{
int b;
public:
void fun(B<int> obj){
auto c = obj.b;
}
};
int main(){
B<char> c;
c.fun(B<int>{});
}
All implementations render an error:
error: 'b' is a private member of 'B
' note: in instantiation of member function 'B
::fun' requested here
This is sufficient to say void B<char>::fun
is not a member of B<int>
(which error happens in the instantiation context), it cannot access the private member of B<int>
, which case is an analogy to the lambda-expression(i.e. closure type).
[expr.prim.lambda.closure] p2 says
The closure type is declared in the smallest block scope, class scope, or namespace scope that contains the corresponding lambda-expression.
If we had a local class inside a member function, I think the members of the local class would also have access. Why should lambdas be different?
If we had a local class inside a member function, I think the members of the local class would also have access. Why should lambdas be different?
Ah, you're right. [class.access.general] p2 explicitly mentions this case:
A member of a class can also access all the members to which the class has access. A local class of a member function may access the same members that the member function itself may access.
Full name of submitter (unless configured in github; will be published with the issue): Jim X
Consider this example:
[class.access.base] p5 says:
The lambda-expression appears in the member of
A
, however,t
is a generic parameter type(i.e. dependent type), and its type is determined when the specialization is instantiated for the calling at#1
. [expr.prim.lambda] just saysIt is not clear whether the specializations of the function call operator template for the genric lambda are considered within the member of
A
such that any specialization can access the private member ofA
.Suggested Resolution
We may insert a phrase in [expr.prim.lambda] to say: