Proposal: Object Destructuring

[no1melman]

It seems to be a common scenario to either do this:

public class Something
{
  public string Name {get;set:}
  public int Age {get;set;}

  public Something(Otherthing other)
  {
    this.Name = other.Name;
    this.Age = other.Age
  }
}

OR

public class Something
{
  public string Name {get;set:}
  public int Age {get;set;}

  public SomethingModel Get()
  {
    return new SomethingModel {
      Name = this.Name,
      Age = this.Age
    }
  }
}

In both of these scenarios, it would be good to just be able to do:

this { ...other }

OR

new SomethingModel { ...this }

I would believe that non-existent properties should be ignored, so if input object has string Else and the target doesn't it should ignore. Obviously this could be consider bad if there was no warning saying properties are missed, it could introduce user bugs.

I would say that this should be exhaustive, so tries to copy over all properties that exist on the input to the target. It should show compiler errors if the types are different.

You may be able to mix with throw expressions:

this { ...other ?? throw new ArgumentException("Properties found to be null") }

Although this would be a tough one, maybe.

I would expect this just to be syntactic sugar, so all the compiler does, is spit out the indivual lines, so resulting in a class that looked like the examples at the top.

Would be nicer than having to go through all the properties and getting them copied over.

[Joe4evr]

This is effectively identical to the "Wither" building block proposed for Records. See #3137 under Non-destructive mutation and data classes.

[theunrepentantgeek]

I believe this would introduce a couple of nasty failure modes for developers maintaining an existing system. When renaming an existing property, you might

• silently cause a value that was being copied across to no longer be copied.
• silently cause a value that was being ignored to now be copied across.

In both these situations, there's no easy way to locate code that might be impacted by the rename affected because the property isn't explicitly referenced anywhere in the line of code.

It's easy to postulate that extensive unit tests would catch the problem - but how many developers write unit tests for things the compiler does automatically? (e.g. I don't write unit tests to check that auto-properties are correctly implemented.)

As outlined by @gafter in #3231

the language's current Opinion is that (Y) elements of APIs between program components should be explicit, intentional choices.

Implicitly copying all matching properties between two otherwise unrelated types would go against the principle currently driving language design. Having the compiler catch situations where things go wrong is extremely useful.