Incremental primary constructor on record

[TahirAhmadov]

record Person(string Name);
record Student(Person original, int Score) : Person(original);
var person = new Person("John");
var student = new Student(person, 5); // all good
// but...
Console.Write(nameof(Student.original)); // this is annoying

Is it possible without original property being synthesized?

[CyrusNajmabadi]

Sorry, it's not clear to me what is annoying here, it what you're asking for help on. Can you clarify? Thanks!

[TahirAhmadov]

Same with your person/personmodel approach. Why would I make a person instance just to throw it away to create the personmodel?

The Person is returned from the ORM or API call; then I "upgrade" it to PersonModel for presentation.

[CyrusNajmabadi]

I can't elegantly, though.

It seems elegant to me. Note: it's not clear to me why you are even using positional parameters here in the first place. You are saying you care about positions, but then don't want people to use them.

Why not just use normal property records here?

[TahirAhmadov]

Why not just use normal property records here?

Too much typing :)

[CyrusNajmabadi]

Those approaches involve repeating the base props for no reason

It's not "no reason". You choose positional construction. So there needs to be a way to indicate how to positionally construct.

But it sounds like you don't even care about positional construction, in which case just normal init properties and a special constructor for copying values over seems a better way to model this.

[CyrusNajmabadi]

Too much typing :)

How so?

[TahirAhmadov]

To clarify what I mean, what I used to do before records:

// this is defined somewhere outside the UI
class Person
{
  public string Name { get; set; } // etc.
}
class PersonsLogic
{
  public Person GetPerson(int id) { ... }
}
// this is defined in the UI (like the web project)
class PersonModel : Person
{
  public PersonModel(Person source, string someDisplayProp)
  {
    AutoMapper.Copy(source, this);
    this.SomeDisplayProp = someDisplayProp;
  }
  public string SomeDisplayProp { get; }
}
// then: 
var person = this._businessLogic.GetPerson(123);
var personModel = new PersonModel(person, this.GetDisplayProp(person));
return this.View(personModel); // or whatever

It would be cool to replace the above with:

// this is defined somewhere outside the UI
record Person(string Name /* etc. */);
class PersonsLogic
{
  public Person GetPerson(int id) { ... }
}
// this is defined in the UI (like the web project)
record PersonModel(base Person source, string SomeDisplayProp) : Person(source);
// then: 
var person = this._businessLogic.GetPerson(123);
var personModel = new PersonModel(person, this.GetDisplayProp(person));
return this.View(personModel); // or whatever

[HaloFour]

Both of you seem to think that the objective here is to deconstruct this record. That is not at all part of this use case.

Which is all the more reason to not use positional records here. Positional deconstruction is one of their use cases.

[TahirAhmadov]

It's one of their use cases, but not a mandated one, is it? Or do you mean that by declaring a record but then not deconstructing it, i'm committing a sin of some sort? The gods of deconstruction will put me in high-ping, 100% CPU and out of memory hell? :)

[HaloFour]

It's one of their use cases, but not a mandated one, is it?

Yes, being able to deconstruct a positional record having symmetry with construction is one of their primary purposes and opinions. Otherwise, I doubt positional records would have been added to the language at all.

[TahirAhmadov]

OK in that case, I'd like to confess, my father. I use records more and more, and don't have a single LoC where I deconstruct them. I beg lord for his mercy. :)

[HaloFour]

That is your choice, but that is the opinion of the design of records, and why you're going to find friction attempting to adapt positional records to this use case.

[spydacarnage]

@spydacarnage so it generates the extension method - basing on what? How do you define the "child" record?

The PersonModel class is tagged with an attribute

[ConvertFrom<Person>]
public record PersonModel( ... )

The source generator then examines the two types, and fills out the method with simple assignments where the they have identical properties. Extra properties in the destination are added to the method's parameter list.

[TahirAhmadov]

What is inside the PersonModel primary ctor?

[spydacarnage]

My version uses init props, like Cyrus' (but with the converter method source-generated).

Your Insistence on using PCs for this hampers your choices a little, but it might still be achievable - the SG would just need to do more work, and you'd have to carefully plan your types.

Or just switch to the method more suited to your requirements instead of trying to shoehorn the one that isn't...

[TahirAhmadov]

I see what you mean. Really though, in that case there is not much a record does for me that a regular class cannot, and the props have boilerplate of their own which PC parameters don't... What you have is better than nothing, but I think I prefer my approach even with the extraneous Person original property present on the child PersonModel record.