Add a property called 'Auto Deconstruction' to 'ValueTupe'

[nczsl]

Add a property called 'Auto Deconstruction' to 'ValueTupe'
like this:

var px=(p1:1,p2:"a");
// px.AutoDeconstruct=true; // add this property

void M(int p1, string p2)
{
Console.WriteLine(p1);
Console.WriteLine(p2);
}
M(px); //error, but we can let it at when AutoDeconstruct is true then it right
// M(px.p1, px.p2);

If the custom member name of the 'ValueType' variable does not match the method parameters to be deconstructed, then according to the usual deconstruction practice, the method should also prevail in this case; So the success or failure of automatic deconstruction is not related to the custom names of members, but only to the number, order, and type of members. As long as these three conditions are met, it should be considered a legal deconstruction rule
Example:

var x1=(p1:1,p2:"abc",p3:true);
void M1(int k1,string k2,bool k3){
//Using k1, k2,k3
}
M1(x1); //  Correct, when x1 is set to AutoDeconstruction=true
void M2(string p1,string p2,bool p3){} 
M2 (x1)//Error, even when x1 is set to AutoDeconstruction=true, it does not work,

[huoyaoyuan]

The requirement is about using tuple to fill multiple arguments when calling methods.
Though it's straight for simple cases, there can be ambiguity when implicit conversion and overload resolution are involved.
This will definitely not a property of the tuple, but an annotation at call site like:

M(..px);

A new syntax is probably required to avoid ambiguity.

[nczsl]

I think what you said makes sense. To avoid ambiguity, use Using operators to do it looks better, more elegant, and intuitive than using attribute control.

[ufcpp]

#1654

[bzd3y]

Am I wrong that the biggest problem here is that the compiler is supposed to know the value of an object's property? I think it is one thing for it to do that for things like tracking nulls or checking for values that a variable can never have. But in this case, you're setting the property, and then what? Can it be set to false again later? Why not? It's not read-only because you set it the first time after the tuple was created. So it's just set once?

Why would AutoDeconstruct ever be false? What is the use case for not wanting a tuple to get deconstructed into a method sometimes but not always?

Then again, the idea of just passing tuples in as parameters doesn't seem to provide much value to me anyway. Why do we need that? It seems like it makes the code less clear, in this case the signature of those methods. Do they take one parameter or 3? This isn't problem for deconstructing the return value of a function because you can see exactly what is happening there.

Anyway, if we really want this, I agree with @huoyaoyuan and it needs to be at the call site and make it clear(er) what is going on (or at least clear that something is going on). So something like one of the following:

M1(px()); // so () after a tuple means "deconstruct" it, or: "as a parameter list"
M1((px)); // the "unnecessary"/"redundant" () _around_ a tuple means "deconstruct" it, or "as a parameter list"