> 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

> 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.