Proposal: primary constructors on records allow for object initializer syntax

[chase-miller]

Summary

Update c# so that all records declared via primary constructor syntax can be instantiated either via constructor syntax or object initializer syntax. All constructor parameters in the record declaration function as required properties such that the consumer must provide them when opting for object initializer syntax.

Example

Record declaration:

public record MyData(string TenantId, string MyCoolVal)
{
    public string[] SomeOptionalProperty { get; init; } = Array.Empty<string>();
}

Initialization via object initializer syntax:

return new MyData
{
    TenantId = "SomeTenant",
    MyCoolVal = "SomeVal",
};

-- or --

Initialization via constructor:

return new MyData(
    TenantId: "SomeTenant",
    MyCoolVal: "SomeVal");

This would fail to compile because TenantId is a required property:

return new MyData
{
    MyCoolVal = "SomeVal",
};

Workaround

We can achieve roughly equivalent functionality from the consumer's perspective via a much more verbose record declaration:

public record MyData
{
    public MyData()
    { }

    [SetsRequiredMembers]
    public MyData(string TenantId, string MyCoolVal)
    {
        this.TenantId = TenantId;
        this.MyCoolVal = MyCoolVal;
    }

    public void Deconstruct(out string tenantId, out string myCoolVal)
    {
        tenantId = TenantId;
        myCoolVal = MyCoolVal;
    }

    public required string TenantId { get; init; }
    public required string MyCoolVal { get; init; }

    public string[] SomeOptionalProperty { get; init; } = Array.Empty<string>();
}

Background and Motivation

Facilitate terser and more readable record declarations for instances where we want to give a consumer the choice of object initializer or constructor syntax.

[tacosontitan]

Facilitate terser and more readable record declarations for instances where we want to give a consumer the choice of object initializer or constructor syntax.

Terse does not always improve legibility. In this case, your proposal is violating expectations on behavior for constructors and object initializer syntax. A constructor specifies required data while object initializer syntax allows for further specification of the instance at initialization and only members explicitly marked as required but not set by the constructor are required to be set at that time.

You can see that with this sample snippet:

// no error about fizz not being set.
var sample = new Sample(foo: "foo") { Bar = "bar" };

// error because bar is not set but is required
var sample = new Sample(foo: "foo") { Fizz = 3 };

public sealed class Sample(string foo)
{
    public string Foo { get; set; } = foo;
    public required string Bar { get; set; }
    public int Fizz { get; init; }
}

[chase-miller]

Can you help me understand the semantic difference between these two snippets of code?

public record Sample(string Foo);

public record Sample
{
    public required string Foo { get; init; }
}

As I understand it they both convey to the consumer that Foo must be provided upon initialization of Sample.

[tacosontitan]

They do convey that Foo must be provided, but how and when they are required to be provided is different.

My point isn't that the two aren't synonymous, it's that your proposal recommends allowing them to be interchangeable which violates expectations. A constructor parameter must be set through the constructor and a required member must be set through object initialization syntax; so imagine specifying a constructor parameter which sets Foo but also marking Foo as required explicitly:

public record Sample(string foo)
{
    public required string Foo { get; set; } = foo;
}

This situation is bad because the argument passed to the constructor is immediately overwritten by the fact that Foo must be set using object initialization syntax which occurs after the constructor is invoked:

var sample = new Sample(foo: "foo") { Foo = "bar" };

_{You can see this for yourself on sharplab.io.}

The important take away is that the constructor is invoked before object initialization occurs, and having the two processes be considered interchangeable violates established expectations of that behavior.

[chase-miller]

Ah that resonates. Thanks for taking the time to help me understand; this is something I hadn't considered. Were this idea to be entertained further perhaps there must be a rule of mutual exclusivity when instantiating an object: either set via constructor or initializer.

That said, don't primary constructors already exhibit the behavior you mentioned whereby a property can be set via both the constructor and property on initialization? Example:

public record Sample(string Foo);

[Test]
public void InitializerStompsOnConstructor()
{
    var sample = new Sample("foo")
    {
        Foo = "bar",
    };
   
    // passes
    sample.Foo.Should().Be("bar"); 
}

If consensus continues to grow that this isn't a great idea, maybe what I'm really looking for is a less verbose way to declare required properties (plus getting the benefit of other primary constructor perks like a compiler-created Deconstruct method). An additional consideration, however, might be how to do this in a way that also achieves the benefit of simpler object hierarchy as discussed here: is there a way for a record to extend a base record via the proposed syntax without needing to redefine all the base record's required properties?

Sorry for being dense, and thanks for taking the time to discuss :-)

[tacosontitan]

That said, don't primary constructors already exhibit the behavior you mentioned whereby a property can be set via both the constructor and property on initialization?

Absolutely, but at that point the constructor argument is still required and the developer is simply shooting themselves in the foot.

[HaloFour]

You could use a source generator to emit a partial type for the record containing a parameterless constructor. But it's intentional that a positional record is required to be created through the primary constructor.