Yatao Li

Ooh, good question! I think in this case, we should keep the type inference as-is (tuple). The deconstruction routines should only be active if `x` is inferred as a non-tuple....

Well, using SRTP defeats the purpose of being C# compatible—which is my main motivation.

@Happypig375 I think @baronfel has already covered the points, but let me try to rephrase: First, the deconstruction methods are not necessarily attached to the types, so type constraints are...

> A shorter name than Deconstruct could also be used Right, that's much better. To avoid clashing with an existing DU case, I'd prefer a new symbol for this new...

I think in practice, most deconstruct methods are used together with a run-time type check. If you know the type ahead of time, you can already call a concrete method...

> Also, it doesn't cooperate well with completeness checking When we tap into OO it's lost already. This is not intended to be used with ADT.

Example from MSDN: ``` using System; public class Person { public string FirstName { get; set; } public string MiddleName { get; set; } public string LastName { get; set;...

@TheJayMann I think your example doesn't work because there's implicit conversion between float and integer -- try string instead?

@abelbraaksma I understand your concern and I fully agree that the deconstruction should be compile-time only. Being best served with run-time type check does not mean it is inherently bound...