Primary constructors in C# 10

[MadsTorgersen]

This discussion is meant to capture open issues around generalized primary constructors beyond C# 9.0 records, for the purposes of discussion in LDM.

There's a slightly dated proposal here: https://github.com/dotnet/csharplang/blob/master/proposals/primary-constructors.md, which isn't too far off, but does not yet reflect decisions made for the records-specific version of the feature in 9.0.

Syntax

I believe we are resolved to the same syntax as we have in records; i.e.:

public class C(int i, string s) : B(s)
{
    ...
}

Semantics

Primary constructors outside of records should not lead to the generation of public properties by default. The original (pre-record) intention, described in the linked proposal, was for them to be captured on demand like in a lambda expression, stored in private fields as an implementation detail, but treated as parameters wherever they are referenced. This would mean that you could reference i in the above example anywhere in the class body, but you could not reference the backing field this.i, or for that matter other.i in the manner of private fields.

The records design brings this into question. In records, the semantics are that a member declaration is generated if one of that name does not already exist. A generalized design for primary constructors could follow the same scheme, with the "small" caveat that instead of a public auto-property, the generated member would be a private field of the same name. Also, in record primary constructors, the constructor parameters are in scope in field and property initializers, and shadow the member of the same name. A similar design for general primary constructors would allow for:

public class C(int i, string s) : B(s)
{
    protected string s = s; // No generated field s; RHS s references the constructor parameter
    void Update(C other) => this.i += other.i; // Generated i available as private field
}

Such a design is further from what we originally envisioned, but much closer to what we already have in records; the only difference being the kind of member generated if one is not explicitly declared.

Primary constructor body

Both in and outside records, the lack of a place to declare a constructor body for a primary constructor sooner or later becomes a problem. Falling off the cliff and turning it into an ordinary constructor declaration is jarring.

We have a proposal for a syntax for this:

public class C(int i, string s) : B(s)
{
    C
    {
        if (s is null) throw new NullArgumentException(nameof(s));
    }
}

I.e. the name of the class followed by a body (could also be an expression body). The parameters would be in scope inside the primary constructor declaration, and would shadow the corresponding fields (which can still be accessed with this.s etc. if we allow that).

We could allow an explicit accessibility modifier on the declaration, which would change the accessibility of the primary constructor.

Direct constructor parameters

The feature has a potential interaction with Direct Constructor Parameters #4024.

Member declarations in primary constructor parameters

If primary constructor parameters can lead to a member being declared, there's a spectrum of possibilities for allowing additional syntax on the parameter to influence that member declaration:

• accessibility modifiers could transfer to the member
• property accessors could transfer to the member, making it a property instead of a field
• attributes (maybe with a field target) could transfer to the member
• potential other old and new modifiers such as readonly, data or required could transfer to the member

Other open design questions?

[alrz]

Primary constructor body

That proposed syntax seems to be lost in the declaration. I would prefer something like:

default C() { } // no parameters allowed; has access to primary ctor parameters

This is similar to static constructors which also can't have parameters.

[HaloFour]

I recall that being suggested and hotly debated on the CodePlex forum. The body of the class would effectively become its own method body with very strange scoping rules. Maybe I'll try to dig the discussion out of the zip archive.

[cessationoftime]

It works wonderfully in Scala. It's my favorite feature of the language.

[burtonrodman]

very much dislike the "anywhere in the class body" idea... even property initializers are hard enough to reason about already in terms of execution order. would prefer "falling off a cliff" (to para Mads) or abbreviated ctor syntax to the "wild west" approach.

can't wait for this to happen though... hate writing (or generating) all this code...

    private readonly ICurrentUserService _currentUserService;
    private readonly IHomePageTextService _homePageTextService;

    public ListModel(
      ICurrentUserService currentUserService,
      IHomePageTextService homePageTextService)
    {
      _currentUserService = currentUserService;
      _homePageTextService = homePageTextService;
    }

[calin-darie]

Can't wait for Member declarations in primary constructor parameters

Is this still being discussed somewhere?

[igalnassi]

Same here, would be extremely helpful and clean

[przemo098]

I vote for Scala solution its commonly known and really simple:
https://www.journaldev.com/9810/scala-primary-constructor-indepth
Also this feature shouold be introduced many C# before...

[daiplusplus]

Other open design questions?

Constructor parameter inheritance, or the lack-thereof, has been a large ergonomic wart in every OOP language I’ve used to-date - I suspect this will get worse with the addition of primary-constructors - and the introduction of primary-constructors provide an opportunity to have C# “bless” a single specific ctor as the single, one and only (Highlander?) primary ctor, and so eliminate overload selection problems entirely.

By “parameter inheritance” - I’m referring to not just the ability for supertype constructors to be pulled-in implicitly as automatically-generated subtype ctors, but that if a supertype’s ctor has, say, 9 parameters, then the subclass should be able to define their own ctor without needing to manually repeat those 9 parameters and pass them through to base(); additionally the subclass should be able to add their own parameters to those 9 - and ideally this would be supported by the ABI (just as supertypes can add new members that existing subtypes inherit, even if their DLL is already compiled).

(It could be hacked-together with the current CLR by using parameter-objects behind-the-scenes, but that has potential to balloon assembly metadata sizes; otherwise doing it “properly” would require .NET to fully support parameter-lists or method-signatures as first-class types in their own right, with support for variance and equivalence (and isomorphism with value-tuples and other types would be nice too).

Syntactically, something like this (and appropriating … from JavaScript too, of course, as a suggested syntax to denote where the inherited params would go). The potential show-stopper problem where one needs to disambiguate ctor overloads is eliminated as there would only ever be one supertype primary ctor to call (assuming a supertype must have a primary ctor, of course).

public class B( Uri a, Object b, short c )
{
}

// C’s ctor inherits all parameters from B’s ctor:
public class C( … ) : B( … )
{
}
// Call-site: new C( uriA, bObj, 123 );

// C adds parameters of its own, with inherited params in the middle:
public class C( string x, …, int y ) : B( … )
{
}
// Call-site: new C( xStr, uriA, bObj, 123, -1 );

Assuming the parameter-list (the type) and argument-list (the values) can be reified then this switching from inheritance to composition without requiring the caller to provide their own composed instance - this would be handy with primary-constructors as it means the call-sites of the former-subclass don’t need to be updated:

// D’s ctor has the same externally-visible signature as C’s
public class D( string x, paramsof(B) bp, int y )
{
    D {
        this.b = new B( bp );
    }
}

Where the paramsof(B) bp operator/syntax refers to the primary-ctor parameter-list of B which can be used inline in any other method signature, regardless of place, and is treated as equivalent to a ValueTuple and/or record-struct (or class?) with the same members (I believe out and ref params would work with this arrangement too), and it can be used as a type-name in a declaration:

So the call-site for D could be any of these:

// Inline parameters and arguments:
new D( “x”, uriA, bObj, 123, y: -1 );

// Equivalence with ValueTuple:
( Uri, object, short ) b_params_as_valuetuple = ( new Uri(“u”), new Object(), 123 );
new D( “x”, b_params_as_valuetuple, -1 );

// paramsof used as a declaration’s type:
paramsof(B) p = b_params_as_valuetuple;
new D( “x”, p, -1 );

[ILAgent]

you could look at Kotlin as a reference implementation

[IanMarteens]

Probably it has been discussed before, so a "shut up, Ian!" won't be taken as a personal offense: why primary constructors, instead of member declaration in ordinary constructors, à la TypeScript? I cannot imagine a reason to pick a single constructor as the "chosen one". It makes sense for records, since records binds that two concepts: a primary constructor and automatic member declarations (and yes, all the thingies related to equality and custom identity). Just my two cents, of course.

[HaloFour]

why primary constructors, instead of member declaration in ordinary constructors, à la TypeScript?

Primary constructors already exist in the language, so it makes sense to use the existing syntax rather than have two separate syntaxes for records vs. non-records.

It's quite possible that the syntax could be extended to support member declarations in the future.

I cannot imagine a reason to pick a single constructor as the "chosen one"

The reason is that the signature of the constructor defines the identifiers in scope in the body of the class. What does it mean to have two different constructors that declare two different sets of members?

In TypeScript, for instance, only a single constructor may declare member parameters, and that has to be the one constructor that has an implementation.

[IanMarteens]

Got it! Thanks.

[FaustVX]

For what I understand, primary constructor is more a syntax than a feature
And for those saying that primary constructor behave differently between record and class/struct, it's already happening :

record R0(int I); // <- Property I is generated

record R1(int I) : R0(I); // <- Property I isn't generated

[MadTiger2409]

I would rather go with Dart constructor specialized for data/fields initialization:

class Car {
	String make;
   	String model;
   	String yearMade;
   	bool hasABS;
   
   	Car(this.make, this.model, this.yearMade, this.hasABS);
}

Current proposal will get a little bit ugly when you add interfaces and generic parameters to the line with class decclaration.

[FaustVX]

Scala approach is excellent as well.

I really don't like Scala approach, everything is mixed-up.

class C(int i)
{
  public int I { get; } = i;
  public int J { get; } = 2;
  public int Double { get; } // = i * J; <- error, can't access this.
  Double = I * J; // should works, because it's in a constructor.
}

I would prefer a single init method

class C(int i)
{
  public int I { get; } = i;
  public int J { get; } = 2;
  public int Double { get; } // = i * J; <- still error, can't access this.
  init()
  {
    Double = I * J;
  }
}

[HaloFour]

@FaustVX

That's legal in Scala:

class Foo(x: Int) {
  val X: Int = x
  val Y: Int = 2
  val Z: Int = x + this.Y
}

I think the issue in C# is more that the compiler is treating the assignment to Y as a direct field assignment since it's a get-only auto-property, but it's treating reading the property as an invocation to the accessor method. If C# treated them as both field access it'd probably be fine. That said, Scala is also fine with an instance method invocation in a field initializer, too, so clearly it's less strict about referencing this in initializers than C# is.

class Foo(x: Int) {
  def getX(): Int = x
  def getY(): Int = 2
  def getZ(): Int = x + getY()
}

[FaustVX]

@HaloFour
To be honest, I've never wrote a single line of code in Scala, I've just read how to write primary constructor with it.
But, from what I've seen, the mix between Properties declaration and statements is ugly and hard to read/understand.

Scala is also fine with an instance method invocation in a field initializer

I don't think this would change in C# just for primary constructor.
So in my examples, I tried to mix the Scala and C# together.

[HaloFour]

@FaustVX

To be honest, I've never wrote a single line of code in Scala

You ain't missin' anything. 😉

But, from what I've seen, the mix between Properties declaration and statements is ugly and hard to read/understand.

I see, so the concern is more about how the language would approach additional statements that would be normally in a constructor body. I probably agree that allowing them directly in the body of the class is probably a bit weird. I don't think that would be addressed in a first pass. Validation would be useful both here and in records so I assume that something will be considered at some point.

I don't think this would change in C# just for primary constructor.

I agree, I'd hope that if anything were considered here that it would be for any C# type. One could make the argument that it would be easier for "simpler" types that don't have constructor bodies, but it would still affect the order in which the initializers would run and would be observable in the worst cases.

[FaustVX]

@HaloFour

You ain't missin' anything. 😉

Haha 😄

I would like to have the init() method to be a validation method to be run after every constructor and with expression called.

class C(int i) { init() { if (I < 0) throw new Exception(); } public int I { get; } = i; }
var c = new C(5); // init called at the end, Exception not thrown
var c1 = c with { I = -5 }; // init called at the end too, Exception thrown

[FaustVX]

I've tried to fiddle around Primary constructors in Sharplab,
But currently, we can't write attributes on primary constructors

[constructor: SetsRequiredMembers] // <-warning CS0658: 'constructor' is not a recognized attribute location. Valid attribute locations for this declaration are 'type'. All attributes in this block will be ignored.
class C<T>(T value) { }

sharplab.io

[ufcpp]

See #3650

[IEvangelist]

Hi friends, I love this feature proposal!

One concern I have is the conflict that arises when contemplating how to name constructor parameters, as they're not only parameters but they're also essentially fields. We're mixing metaphors a bit, and when that happens developers tend to argue, specifically over naming conventions. More often than not, fields are prefixed with _, and this has proven to be an industry standard and a convenience as you can type a leading _ and quickly discover the fields in scope.

The currently proposed syntax is as follows:

public class Person(string firstName, string lastName)
{
}

My concern is that while the parameter names look good, the field names are forced to match that of the parameter. One possible counter-argument is to name your parameters as you'd like your fields to be named:

public class Person(string _firstName, string _lastName)
{
}

But this conflicts with industry-standard naming conventions for parameters. I'd like to propose an optional syntax to express an alternative name for the field, whilst keeping the name of the parameter.

public class Person(string _firstName: firstName, string _lastName: lastName)
{
}

This would be an optional syntax, that allows the developer to define their field names. When it comes to the ability to express defaults, the syntax would look like this:

public class Person(string _firstName: firstName = "David", string _lastName: lastName = "Pine")
{
}

[HaloFour]

The primary constructor parameters aren't fields. They are parameters that have a scope across the body of the type. If you only use them within the lifecycle of construction, such as in a base constructor call or initializers, then they have no corresponding storage in the type. If you reference the parameter outside of that lifecycle then they are captured as private fields with unspeakable names, similarly to auto-properties. As such field naming convention concerns don't really apply.

For example, no fields are emitted for the code examples you provided:

// given
public class Person(string firstName, string lastName)
{
}

// equivalent to
public class Person
{
    public Person(string firstName, string lastName) { }
}

Future iterations to the feature may allow more explicit specification of members to be synthesized, e.g. fields or properties. Maybe that would enable specifying different names per member, although I personally think that's overkill. The naming conventions apply more to cases where you may reference the same members in different ways in the same scope, e.g. a parameter vs. a field vs. a property, which doesn't really apply here.

[CyrusNajmabadi]

We're mixing metaphors a bit,

Yes. this came up during the last ldm convo here. We def want to hear what the ecosystem thinks here to determien what other steps to take. Thanks a lot for the feedback!

[amal-stack]

[UPDATE]: Opened #7028 suggesting the following.

This is a cool feature to have. At the moment, the scope of the constructor parameters is restricted to the body of the constructor and extended on demand via backing fields as references of them begin to appear in the containing class. This, as many have pointed out, could lead to confusion and the behavior would not maintain parity with that of positional records.

To be more flexible and explicit, a way to specify the target of the arguments could be implemented. The target can be:

field                     // Assign to a field
get, set                  // Assign to a read-write Property 
get                       // Assign to a read-only Property
readonly field            // Assign to a read-only field

The target could be specified in an as or params clause:

class Person(string FirstName, string LastName) as get, set 
{
}
// OR
class Person(string FirstName, string LastName) params : get, set
{
}

[HaloFour]

It's intentional that primary constructors does not have feature parity with positional records. The goal is to decompose positional records into two orthogonal features, records and primary constructors, that when combined provide the same features of positional records. The member synthesis aspect of that would be provided by records. That allows use of primary constructors in non-record types without having to ascribe to all of the other opinions that come with records.

[amal-stack]

@HaloFour However, in the current case, members are still synthesized in some cases. For instance, nothing stops one from writing code like this:

class Person (string name)
{
    public bool NameStartsWith(char letter) => name.StartsWith(letter);
}

Here, name in the NameStartsWith() method is effectively a reference to a synthesized private field.

If, in the future, the following syntax has to be supported (#6871):

class Person(string FirstName, string LastName);

private fields would definitely not make sense. One would expect them to be properties which is also happens to be what positional records synthesize whether they have a body {} or end with a semicolon ;.

[HaloFour]

Here, name in the NameStartsWith() method is effectively a reference to a synthesized private field.

Yes, but that is an implementation detail, which is why the field is not called name and cannot be referenced by this.name. Captures for lambdas also synthesize fields.

If, in the future, the following syntax has to be supported

It will already be supported, but no members will be synthesized. If you want member synthesis, apply the record keyword. It is the combination of the two that will enable positional records, not primary constructors alone.