4 ms·

No, it doesn't make sense. Order coupling between destructuring assignment targets and class fields is very similar to order coupling between formal and actual

No, it doesn't make sense. Order coupling between destructuring assignment targets and class fields is very similar to order coupling between formal and actual parameters of functions, which is easier to get wrong and for which no protection exists. Struct X could have a constructor public X(int first,int second):a{first},b{second} but a caller intending to set a=1 and b=2 could call X(2,1) instead (particularly if last time they checked the constructor was public X(int first,int second):b{first},a{second}). You certainly don't want to prevent this "mistake" by enforcing that the first parameter must be a local variable called a and the second must be a local variable called b and that the constructor parameters must be called a and b too. This sort of easily detected error is exactly the same as writing [b,a] instead of [a,b] in a deconstructing assignment. Treating a sequence of fields in a class as a tuple is "unusual and slightly flaky" because few and unimportant languages do it, because it's very new for C++, and because it faces complications like inheritance, not because it is wrong or bad; someone might be slow to adapt, but everyone else will benefit. In practice, only very plain and well documented structs will be suitable for deconstructing assignment; for example, in code generated from data serialization schemas there is a natural and well known order for class members.

cannam 8y ago
> a caller intending to set a=1 and b=2 could call X(2,1) instead [...] You certainly don't want to prevent this "mistake" by enforcing that the first parameter must be a local variable called a and the second must be a local variable called b and that the constructor parameters must be called a and b too. An Objective-C programmer might disagree with the last part. But of course it's possible to come up with examples of other things already in C++ that are equally error-prone. That doesn't mean this new thing won't be error-prone too. I bet that many C++ programmers who are passingly familiar with C++17 would agree that the second line here: struct { int a; int b; } x { 1, 2 }; auto [a, b] = x; is syntactic sugar for auto a = x.a; auto b = x.b; Introductory material about structured bindings routinely uses examples like this, where the names happen to match those in the structure, without making it clear that this is not what actually goes on. > This sort of easily detected error "Easily detected" in C++ means the compiler detects it. The rest might as well be Javascript. > Treating a sequence of fields in a class as a tuple is "unusual and slightly flaky" because few and unimportant languages do it Can you name one? This is one thing I've been trying to discover here, without success. > In practice, only very plain and well documented structs will be suitable for deconstructing assignment I do agree with this -- good practice should be to use it only for "obvious" cases. I will use this feature, when I get the opportunity. I use element-wise structure initialisation often enough. It's convenient, this will be convenient. It also bites me occasionally and so will this.

cannam 8y ago

> a caller intending to set a=1 and b=2 could call X(2,1) instead [...] You certainly don't want to prevent this "mistake" by enforcing that the first parameter must be a local variable called a and the second must be a local variable called b and that the constructor parameters must be called a and b too. An Objective-C programmer might disagree with the last part. But of course it's possible to come up with examples of other things already in C++ that are equally error-prone. That doesn't mean this new thing won't be error-prone too. I bet that many C++ programmers who are passingly familiar with C++17 would agree that the second line here: struct { int a; int b; } x { 1, 2 }; auto [a, b] = x; is syntactic sugar for auto a = x.a; auto b = x.b; Introductory material about structured bindings routinely uses examples like this, where the names happen to match those in the structure, without making it clear that this is not what actually goes on. > This sort of easily detected error "Easily detected" in C++ means the compiler detects it. The rest might as well be Javascript. > Treating a sequence of fields in a class as a tuple is "unusual and slightly flaky" because few and unimportant languages do it Can you name one? This is one thing I've been trying to discover here, without success. > In practice, only very plain and well documented structs will be suitable for deconstructing assignment I do agree with this -- good practice should be to use it only for "obvious" cases. I will use this feature, when I get the opportunity. I use element-wise structure initialisation often enough. It's convenient, this will be convenient. It also bites me occasionally and so will this.