This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-11-11

751. Deriving from closure classes

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

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; }) ...

Proposed resolution (July, 2009)

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