C++0x: Protected/private member access from lambda functions

[Raymond Kraesig]

struct A {
friend std::tr1::function<void(A&, int)> F();
friend std::tr1::function<void(int)> F2(A&);

private:
int v;
void pf() {}
};

std::tr1::function<void(A&, int)> F() {
return [] (A&a, int i) { a.pf(); a.v = i; };
}

std::tr1::function<void(int)> F2(A &a) {
return [&a] (int i) { a.pf(); a.v = i; };
}

-------------------

A read-through of N2550 does not seem to imply that a lambda-function
declared inside a friend of a given class inherits that friend's
member access rights, and that therefore both F() and F2() above would
be ill-formed. In fact, it doesn't even appear to allow inheritance of
member access rights when declared in an actual member function.

Is this a correct reading of N2550? If so, is it an intentional
effect? I wouldn't think that it would be useful to restrict lambda
functions in such a fashion, given that std::tr1::bind() can create
closure-objects even today that are equivalent to lambda-functions
with inherited friendship, simply by explicit closure over
pointers-to-members and pointers-to-member-functions. (I don't think
I'd enjoy continuing to do that, though.)

-- Ray

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[ymett]

On Mar 15, 10:17 pm, Raymond Kraesig <raymond.krae...@earthblink.net>
wrote:

> A read-through of N2550 does not seem to imply that a lambda-function
> declared inside a friend of a given class inherits that friend's
> member access rights, and that therefore both F() and F2() above would
> be ill-formed. In fact, it doesn't even appear to allow inheritance of
> member access rights when declared in an actual member function.
>
> Is this a correct reading of N2550? If so, is it an intentional
> effect? I wouldn't think that it would be useful to restrict lambda
> functions in such a fashion, given that std::tr1::bind() can create
> closure-objects even today that are equivalent to lambda-functions
> with inherited friendship, simply by explicit closure over
> pointers-to-members and pointers-to-member-functions. (I don't think
> I'd enjoy continuing to do that, though.)

N2798 5.1.1p7 says:
The type of the closure object is a class with a unique name, call it
F, considered to be defined at the point where the lambda expression
occurs.

I think that means it is a local class in the and has all access
rights its enclosing function has.

Yechezkel Mett