[dcl.struct.bind] structured bindings vs. potentially conflict #5201

xmh0511 · 2022-01-12T05:56:41Z

@opensdh As have discussed in this thread: https://stackoverflow.com/questions/65729849/it-seems-the-current-standard-draft-cannot-interpret-why-two-structured-binding

struct A{
    int a;
};
struct B{
    int b;
};
auto&& [x] = A{};  //#1
auto&& [x] = B{};  //#2
int main(){
}

There is no provision in the current draft that can point out the name x at #1 potentially conflicts with x at #2. In short, [basic.scope.scope] p4 is saying they correspond, [basic.link] p8 is saying they declare the same entity, obviously, their shared name denotes the same entity, and also [basic.link] p11 didn't even mention structured bindings. Finally, [basic.def.odr] also didn't mention it. Furthermore, except for this example, there is also a similar example:

struct C{
    int a; 
    int b;
};
auto [x, x] = C{0,0};

[dcl.struct.bind] p1 is saying

A structured binding declaration introduces the identifiers v₀, v₁, v₂, ... of the identifier-list as names of structured bindings.

So, each name of the identifier denotes the corresponding structured binding introduced by a structured binding declaration. Obviously, [basic.pre] p5 is wrong in this case, which says

An entity E is denoted by the name (if any) that is introduced by a declaration of E or by a typedef-name introduced by a declaration specifying E.

I would argue that a structured binding declaration can introduce multiple structured bindings(entities). Obviously, the relationship between them is not one-to-one. Moreover, [basic.pre] p3 admits that "structured binding" itself is a distinct category of the entity. So, we should regulate which structured bindings declare the same entity or not.

@opensdh has given the patch but it seems to be not ok for the second example

This is just a missing case in [basic.link]/11: that if one (of the two declarations) declares a structured binding, the program is ill-formed.

The condition of [basic.link] is

For any two declarations of an entity E

In the second example of this issue, the entity E denoted by the two names x is introduced by the same structured binding declaration. Presumably, [basic.link] also never intends to compare any two declarations by using the same declaration as two declarations, this does not make sense.

The text was updated successfully, but these errors were encountered:

jensmaurer · 2022-01-12T08:38:02Z

A declaration can have several declarations inside, and I think that's exactly what a structure binding declaration does: [a, b] = f() declares two structured bindings (entities), a and b.

@opensdh, it looks like [basic.link] p11 should mention structured bindings.

basic.def.odr, after my rewrite in a recent core issue, should already say the right thing that we can't have a redefinition of a structured binding.

xmh0511 · 2022-01-12T09:59:07Z

@jensmaurer

A /declaration/ can have several declarations inside

Sure, using A = struct B{}; is an instance. However, a structured binding declaration is a bit different since there are no more declarations nested in the structured binding declaration.

An entity E is denoted by the name (if any) that is introduced by a declaration of E

The wording "a declaration of E" sounds like that the declaration is uniquely possessed by the entity E. This makes the following example hard to interpret

auto [a, b] = f(); // #1
int c, d;  // #2

Either at #1 or #2, there is only one declaration, which can introduce more than one entity. the entities denoted by a and b share the declaration at #1, c and d share a declaration at #2. Either declaration is not uniquely possessed by one of the entities. Maybe, we can argue we have [dcl.decl.general] p3 for #2 to make the declaration can be divided into two declarations for the concept. However, we have no such extra statement for the structured binding case. So, I think we may change the above sentence to that

An entity E is denoted by the name (if any) that is introduced by a declaration introducing E.

which can eliminate the puzzle of the "ownership".

Also, [basic.scope.scope] p4 has a bit issue on structured binding cases

Two declarations correspond if they (re)introduce the same name...

In this case

auto [x, x] = f();

there is only one declaration here, which introduces two structured binding with the same name. So, we couldn't determine certain concepts based on the "correspond".

jensmaurer · 2022-01-12T12:17:13Z

As I said, the model here is that int a, b; is two declarations (prose term) (one for a, one for b), even though it is only one (grammatical) declaration. With that interpretation, auto [x,x] = f() is clearly ill-formed. (The declaration of a structured binding is a definition, and we have duplicate definitions for "x" here.)

xmh0511 · 2022-01-12T12:42:27Z

As I said, the model here is that int a, b; is two declarations (prose term) (one for a, one for b)

I agree with this point since we have [dcl.decl.general] p3 that explicitly clarifies this point

Each init-declarator or member-declarator in a declaration is analyzed separately as if it were in a declaration by itself.

In other words, each init-declarator is considered as if it were in a single corresponding declaration.

But, how about a structured binding declaration? we never define a similar concept to clarify that each structured binding has its own declaration for analysis.

jensmaurer · 2022-01-12T15:45:25Z

But, how about a structured binding declaration?

It should be treated the same, but we seem to be lacking words to that effect.

xmh0511 · 2022-01-13T07:10:43Z

but we seem to be lacking words to that effect.

Well, that's a part of what I'm looking forward to in this issue. We should specify that part in the current draft.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[dcl.struct.bind] structured bindings vs. potentially conflict #5201

[dcl.struct.bind] structured bindings vs. potentially conflict #5201

xmh0511 commented Jan 12, 2022 •

edited

jensmaurer commented Jan 12, 2022 •

edited

xmh0511 commented Jan 12, 2022 •

edited

jensmaurer commented Jan 12, 2022

xmh0511 commented Jan 12, 2022 •

edited

jensmaurer commented Jan 12, 2022 •

edited

xmh0511 commented Jan 13, 2022

[dcl.struct.bind] structured bindings vs. potentially conflict #5201

[dcl.struct.bind] structured bindings vs. potentially conflict #5201

Comments

xmh0511 commented Jan 12, 2022 • edited

jensmaurer commented Jan 12, 2022 • edited

xmh0511 commented Jan 12, 2022 • edited

jensmaurer commented Jan 12, 2022

xmh0511 commented Jan 12, 2022 • edited

jensmaurer commented Jan 12, 2022 • edited

xmh0511 commented Jan 13, 2022

xmh0511 commented Jan 12, 2022 •

edited

jensmaurer commented Jan 12, 2022 •

edited

xmh0511 commented Jan 12, 2022 •

edited

xmh0511 commented Jan 12, 2022 •

edited

jensmaurer commented Jan 12, 2022 •

edited