[Discussion] Lighter Tuple Deconstruction

[jcouv]

@mharthoorn commented on Thu Aug 25 2016

The current plan of having Deconstruct methods in a class, is like planning for the unknown. You might have to add a lot of Deconstruct methods to catch all scenarios. It's a lot of code duplication and a lot might not get used.

Would combining tuple syntax with dot syntax work for on-the-spot deconstruction here?

var p = new Point(1, 4);
(int x, int y) = p.(X, Y);

A more extended example:

   class User
   {
       public string FirstName { get; }
       public string LastName { get; }
   }
   ...
   (string first, string last) = user.(FirstName, LastName.ToUpper());

The proposal basically is that .( , , ) syntax would put the public properties, fields (and maybe methods?) of the instance before it in scope.

update:
The more relevant case arises when deconstructing a return value:

(var first, var last) = GetUser().(FirstName, LastName);

If csharp is going to allow tuples as an argument-list (named splatting #347), tuples could work as a bridge: we would have a two way mapping (deconstruction - construction route) with this syntax:

  var user = new User (GetPerson(id).(FirstName, LastName));

---

@alrz commented on Thu Aug 25 2016

AFAIK property patterns are up for the next version.

let {X: var x, Y: var y} = p;
let {FirstName: var first, LastName: var last} = user;

or something like that.

---

@mharthoorn commented on Thu Aug 25 2016

@alrz actually it's a response to @MadsTorgersen blog about c#7 features
https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/
where he mentions the Deconstruct method:

  public void Deconstruct(out int x, out int y) { x = X; y = Y; }

But with regards to the property patterns example you give, this is slightly clearer reading, would you agree?

  (var first, var last) = user.(FirstName, LastName);

And more csharp-ish.

---

@HaloFour commented on Thu Aug 25 2016

Deconstruction is intended to be a positional operation, the inverse of a constructor. You cannot achieve that with properties; you'll always be required to explicitly spell out every property name. By using an instance method it also allows for "extension deconstructors" to be defined.

If you wanted to construct and deconstruct a tuple from an existing type without positional deconstruction you could always use:

(var first, var last) = (user.FirstName, user.LastName);

But the question would obviously be why?

---

@gulbanana commented on Fri Aug 26 2016

i'm concerned that property patterns are redundant with non-tuple deconstruction. it'd be great to unify their syntax (and functionality). it would be worth delaying deconstruction if necessary to achieve this

---

@mharthoorn commented on Fri Aug 26 2016

@HaloFour, I understand what you mean. There is added value though, when you want to deconstruct a return value:

(var first, var last) = GetUser(id).(FirstName, LastName);

---

@HaloFour commented on Fri Aug 26 2016

@gulbanana

i'm concerned that property patterns are redundant with non-tuple deconstruction.

They're not. Property patterns are named whereas deconstruction is positional. Property patterns will apply more to larger classes. Deconstructors will apply more to those smaller classes that behave more like tuples, and eventually to records and discriminated unions. Think KeyValuePair<K, V>. I imagine that most types won't have or need deconstructors.

@mharthoorn

That is what property patterns will be for. It is a shame that they won't make it in C# 7.0.

---

@CnSimonChan commented on Fri Aug 26 2016

I think it's better described as a new way to create tuples (from normal object), but not about deconstruction.

It's better than Property patterns because when you are typing user.(, the compiler knows the type of user and can list its children for you.

But I'm not sure about whether it have enough use cases so it's worth the change, and the syntax looks a little bit strange for me.

And at another perspective, can it be used as the target of deconstruction? Like user.(FirstName, LastName) = GetName(id);, I think this usage can make it more useful.

---

@gulbanana commented on Fri Aug 26 2016

ok but: what if I want to pattern-match positionally? what if I want to deconstruct-assign by name? why should these be different features, basically

---

@HaloFour commented on Fri Aug 26 2016

@gulbanana

what if I want to pattern-match positionally?

var kvp = new KeyValuePair<int, string>(123, "456");

if (kvp is (123, var value)) { ... }

what if I want to deconstruct-assign by name?

That will already be supported:

(var first, var last) = (user.FirstName, user.LastName);

And, with pattern matching (depending on how the proposals evolve towards C# 8.0):

if (user is { FirstName is var first, LastName is "Smith" }) {
    Console.WriteLine("Hello Mr. Smith!");
}

why should these be different features, basically

Because deconstruction is nicer in many contexts, particularly when matching records or discriminated unions where the names are effectively noise. Positional deconstruction is already necessary for tuples, and it's been requested numerous times that it extend to simpler types that behave more like tuples.

---

@gulbanana commented on Fri Aug 26 2016

you've just described near-100% overlap between the features though. the only salient difference I see is that pattern matching can fail - is there no way to reconcile these things??

surely being able to use any pattern in assignment position is strictly more powerful than a separate decomposition feature, as well as being more regular and learnable.

---

@PhotoAtomic commented on Mon Aug 29 2016

it is not completely clear to me if the proposed "Deconstruct" Method name is for the moment a placeholder or something that is stabilized, I just want to point out that legacy code that already has a "Deconstruct" method may exists and this can cause any sort of breaking changes. I think a specific special syntax is required for Deconstruct method

---

@HaloFour commented on Mon Aug 29 2016

@PhotoAtomic I'd imagine that the proposal is pretty close to finalized. I wouldn't expect it to change much, if at all.

I just want to point out that legacy code that already has a "Deconstruct" method may exists and this can cause any sort of breaking changes

That code wouldn't be affected by this change at all. The proposal specifically specifies what signature that such a method would need to have in order to be recognized as a deconstruction method. But you may continue to define methods with that name (and signature) and call them directly.

---

@PhotoAtomic commented on Mon Aug 29 2016

I see, so the team is assuming that no legacy code has a public void Deconstruct() with one or more out parameters. One may be tempted to start writing method with such signature now just to see what happens... :) To me it will be better if some sort of explicit contract (like implementing IDisposable interface) will enable this mechanism, or a special syntax (not available before) to declare the Deconstructor, or a special decoration via attribute maybe. Just relying on the signature doesn't guarantee nothing expecially if it is something that is legal to write with the previous version of the language :( or am I missing something?

---

@HaloFour commented on Mon Aug 29 2016

I see, so the team is assuming that no legacy code has a public void Deconstruct() with one or more out parameters. One may be tempted to start writing method with such signature now just to see what happens... :)

They're likely assuming that it's pretty rare, but it wouldn't matter as the compiler would still respect it as a normal method. The only thing that changes with C# 7.0 is that you'd also be able to use that method with deconstruction:

public class Foo {
    public void Deconstruct(out int x, out int y) {
        x = 1;
        y = 2;
    }
}

// legal C# 6.0
var foo = new Foo();
int x, y;
foo.Deconstruct(out x, out y);

// legal C# 7.0
var foo = new Foo();
int x, y;
foo.Deconstruct(out x, out y);
// and
var (x, y) = foo;