This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

3119. Program-definedness of closure types

Section: 99 [defns.program.defined.spec] Status: WP Submitter: Hubert Tong Opened: 2018-06-09 Last modified: 2019-02-27

Priority: 2

View all issues with WP status.


The description of closure types in [expr.prim.lambda.closure] says:

An implementation may define the closure type differently […]

The proposed resolution to LWG 2139 defines a "program-defined type" to be a

class type or enumeration type that is not part of the C++ standard library and not defined by the implementation, or an instantiation of a program-defined specialization

I am not sure that the intent of whether closure types are or are not program-defined types is clearly conveyed by the wording.

[2018-06-23 after reflector discussion]

Priority set to 2

[2018-08-14 Casey provides additional discussion and a Proposed Resolution]

We use the term "program-defined" in the library specification to ensure that two users cannot create conflicts in a component in namespace std by specifying different behaviors for the same type. For example, we allow users to specialize common_type when at least one of the parameters is a program-defined type. Since two users cannot define the same program-defined type, this rule prevents two users (or libraries) defining the same specialization of std::common_type.

Since it's guaranteed that even distinct utterances of identical lambda expressions produce closures with distinct types ( [expr.prim.lambda.closure]), adding closure types to our term "program-defined type" is consistent with the intended use despite that such types are technically defined by the implementation.

Previous resolution [SUPERSEDED]:

This wording is relative to N4762.

[2018-08-23 Batavia Issues processing]

Updated wording

[2018-11 San Diego Thursday night issue processing]

Status to Ready.

Proposed resolution:

This wording is relative to N4762.