[basic.def.odr] Make example 6 much less confusing #6384
Conversation
|
I personally like the near-symmetry of the examples to show the effective differences. Since we're talking about the ODR here, it seems rather obvious that runtime execution plays no role. If you feel a cross-reference to [expr.prim.lambda.closure] is missing, then let's add that. If you feel a comment saying "closure type defined in the scope of X" is needed, then let's add that. But putting "ill-formed" when we mean "IFNDR" is not a good direction. |
Even if the recursion was to stay, there is a way to get recursion here with fewer parameters and thus distractions: -inline void f(bool cond, void (*p)()) {
- if (cond) f(false, []{});
+inline void f(void (*p)()) {
+ if (!p) f([]{}); // closure type declared inside of f()
}
-inline void g(bool cond, void (*p)() = []{}) {
- if (cond) g(false);
+inline void g(void (*p)() = []{}) {
+ if (!p) g(); // closure type declared outside of g()
}
struct X {
- void h(bool cond, void (*p)() = []{}) {
- if (cond) g(false);
+ void h(void (*p)() = []{}) {
+ if (!p) h(); // closure type declared inside of X
}
};Personally, I think that now which version you use here, the recursion is misleading because it implies that the location of the function call to |
Related: #6364.
Let me start by saying that together with other members of the community whom I consider to be experts, we have spent literally hours trying to figure out the restrictions imposed by the ODR for lambda expressions.
Example 6 has greatly contributed to our confusion, for a number of reasons:
boolparameter to the function. It took us a while to understand that the recursion has nothing to do with the ODR, and everything to do with the point of declaration of the closure type.f.fis the most simple example, and actually requires no parameters.