Title
Deriving from closure classes
Status
cd2
Section
7.5.5 [expr.prim.lambda]
Submitter
Daveed Vandevoorde

Created on 2008-12-11.00:00:00 last changed 143 months ago

Messages

Date: 2009-07-15.00:00:00

[Voted into the WP at the July, 2009 meeting as part of N2927.]

Date: 2009-07-15.00:00:00

Proposed resolution (July, 2009)

See document PL22.16/09-0117 = WG21 N2927.

Date: 2008-12-11.00:00:00

During the discussion of issue 750, it was suggested that an implementation might be permitted to omit fields in the closure object of a lambda expression if the implementation does not need them to address the corresponding automatic variables. If permitted, this implementation choice might be visible to the program via inheritance. Consider:

    void f() {
      int const N = 10;
      typedef decltype([&N](){}) F;
      struct X: F {
        void n() { float z[N]; } // Error?
      };
    }

If it is implementation-defined or unspecified whether the reference member F::N will exist, then it is unknown whether the the reference to N in X::n() will be an error (because lookup finds F::N, which is private) or well-formed (because there is no F::N, so the reference is to the local automatic variable).

If implementations can omit fields, the implementation dependency might be addressed by either treating the lookup “as if” the fields existed, even if they are not present in the object layout, or by defining the names of the fields in the closure class to be unique identifiers, similar to the names of unnamed namespaces (9.8.2.2 [namespace.unnamed]).

Another suggestion was made that derivation from a closure class should be prohibited, at least for now. However, it was pointed out that inheritance is frequently used to give stateless function objects some state, suggesting a use case along the lines of:

    template<class T> struct SomeState: T {
      // ...
    };
    template<class F, typename T< void algo(T functor, ...) {
      SomeState<T< state(functor);
      ...
    }

    ... algo([](int a){ return 2*a; }) ...
History
Date User Action Args
2010-03-29 00:00:00adminsetstatus: wp -> cd2
2009-11-08 00:00:00adminsetstatus: dr -> wp
2009-08-03 00:00:00adminsetmessages: + msg2231
2009-08-03 00:00:00adminsetstatus: review -> dr
2009-03-23 00:00:00adminsetmessages: + msg1897
2009-03-23 00:00:00adminsetstatus: open -> review
2008-12-11 00:00:00admincreate