Nominal Parameter Lists (aka Required Properties)

[333fred]

Nominal Parameter Lists (aka Required Properties)

An updated version of this is now in pr: #4493.

A few months ago, I submitted #3630, which proposed a way for type authors to require that properties are initialized when a type is created, rather than in the constructor. Since then, a small group has been hard at work brainstorming and refining this proposal. We discussed the initial proposal in LDM here: https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-09-16.md#required-properties. Since that meeting, we've been working on the next version of the proposal based on feedback, and I'm happy to present that vision here.

Detailed Design

Syntax

We propose adding a new syntax for property parameter lists, which can be added to constructors to require that the consumer of a constructor initializes the properties in that list. If a constructor chains to a different constructor (such as this or base), it inherits the property parameter list from that constructor, and can modify the list via it's own property parameter list. Here's an example of the syntax with a traditional class:

class Person
{
    public string FirstName { get; init; }
    public string LastName { get; init; }

    // The new syntax is init { PropertyList }
    public Person() init { FirstName, LastName }
    {}
}

class Student : Person
{
    public int Id { get; init; }

    // The base() init call implies the property parameter list from Person,
    // which is FirstName and LastName. It is then added to with another property
    // list, which adds a requirement that Id is initialized.
    public Student() : base() init { Id }
    {}
}

Property parameter lists can use assignments to remove requirements inherited from base constructors. Assignments can reference regular parameters, use constant values, or assign a discard to indicate that the body of the constructor will perform a more complicated assignment.

class Rectangle
{
    public int Length { get; init; }
    public int Width { get; init; }

    public Rectangle() init { Length, Width }
}

class Square : Rectangle
{
    public Square(int side) : base() init { Length = side, Width = side }
    {
        // Assignments are actually run here, before any user code
    }

    // Another way of expressing this, if you had a more complicated algorithm:

    public Square(int side) : base() init { Length = _, Width = _ }
    {
        var transformed = transformSideLength(side);
        Length = transformed;
        Width = transformed;

        static void transformSideLength(int side) { ... }
    }
}

Derived constructors must include a property parameter list in order to pass the chained constructor requirements along, even if the list is empty. Leaving the property parameter list off indicates that consumers do not have to set anything. This allows users to adopt required properties in base types where it makes sense, while not breaking consumers who already depend on an existing constructor signature.

class Laptop
{
    float ScreenSize { get; set; }
    float ProcessorFrequency { get; set; }

    public Laptop() init { ScreenSize, ProcessorFrequency }
    {}
}

class Surface : Laptop
{
    // Passes all requirements onto consumers.
    public Surface() : base() init { }
    {}

    // Passes any requirements from `base()` not specified in `init` onto consumers. If new properties are added to the base
    // (perhaps laptop comes from a different assembly) it is the consumer's responsibility to initialize.
    public Surface(Surface original) : base() init { ScreenSize = original.ScreenSize, ProcessorFrequency = original.ProcessorFrequency }
    {}

    // Does not pass any requirements onto consumers. New properties added to the base are not the consumer's responsibility
    // to initialize.
    public Surface(Surface original) : base()
    {
        this.ScreenSize = original.ScreenSize;
        this.ProcessorFrequency = original.ProcessorFrequency;
    }
}

Property parameter lists can reference any property that is settable by callers of the constructor. Any inherited property that is not settable by callers must be set in the constructor that inherits it. This means a protected constructor on an abstract class could reference a property that is only settable by derived types, which will force the derived type to set that property itself:

abstract class BoundNode
{
    public BoundKind Kind { get; protected init; }

    protected BoundNode() init { Kind }
    {}
}

sealed class BoundPropertyAccess : BoundNode
{
    // Good: Kind is assigned by this constructor and not passed to consumers
    public BoundPropertyAccess() : base() init { Kind = BoundKind.PropertyAccess }
    { }
}

sealed class BoundFieldAccess : BoundNode
{
    // Error: Kind is passed to consumers, but it is not accessible to them. Compiler error results.
    public BoundFieldAccess() : base() init { }
}

Each constructor can specify its own property parameter list. This means that copy constructors, for example, can specify nothing, as callers do not have to set anything, while the standard parameterless constructor can require a user to specify everything.

We're still designing how primary constructors will look in general, but this should interact well them. Rewriting a couple previous examples using records:

record Person() init { FirstName, LastName }
{
    public string FirstName { get; init; }
    public string LastName { get; init; }
}

record Student() : Person() init { Id }
{
    public int Id { get; init; }
}

record Rectangle() init { Length, Width }
{
    public int Length { get; init; }
    public int Width { get; init; }
}

// In order to avoid declaring a new property, Length had to be reused.
record Square(int Length) : Rectangle() init { Length = Length, Width = Length };

// Alternatively, the base constructor could be called without an init { },
// not passing any additional requirements onto consumers.
record Square(int Length) : Rectangle()
{
    public Square
    {
        Length = Length;
        Width = Length;
    }
}

Enforcement

Requirements are enforced at the point of construction, not on the type itself: an object creation expression that calls a constructor with a non-empty property parameter list must also include an object initializer that sets the properties. Constructors expose 2 types of metadata: a list properties that they require, and a chained constructor whose property parameter list must be followed. This second bit is also optionally accompanied by a list of properties from the chained constructor that are not required. These will likely be encoded as attributes on the constructor, and marking the constructor itself with a modreq that indicates it has a property parameter list.

When inheriting from a chained constructor, any property that is not accessible to potential callers of the constructor must be initialized the inheritor. For example, a base constructor could require an internal property be set, but a public derived constructor would have to set that property, as not all consumers will be able to access that internal property to set it. This also applies to hidden properties: if a required property from the base is hidden with a new property in the derived type, the derived type must initialize it.

Enforcement in the body of a chained constructor that uses a discard assignment to remove a requirement is discussed in open questions below.

Open Questions

Enforcement of discard assignments in chained constructors

We allow a constructor that chains to another constructor to remove a requirement using Property = _ syntax, and that requires that constructor to assign the property in its body. There are a couple of potential ways we could enforce this requirement:

1. Require an explicit assignment to the property in the body of the constructor. This is the most strict version, but it might not be very user-friendly. One common issue we heard with the initial release of NRT was that users might have a helper method that initializes a property the same way from multiple constructors, and we added MemberNotNull in order to address these complaints. If we require the property to be definitely assigned the body and only in the body of the constructor, we re-add this problem back to the language after we removed it in C# 9. For a reason known as the halting problem we aren't interested in performing the definite assignment rules across method boundaries, so that would require us to invent a second meta-language for property assignments, separate from the nullable meta-language.
2. Leverage nullable itself. We'd require that, at the end of a constructor body, the nullable state of the property must be consistent with its declaration. This allows us to leverage the same meta-language that we created for nullable and not introduce a nearly-identical system for definite assignment. There are a few immediate problems with this: what happens if the user doesn't have nullable enabled? Do we just give up on enforcement entirely? It also has the unfortunate problem of conflating nullability and requiredness, which the rest of this proposal explicitly attempted to avoid. The benefits may be worth it, but we need to look more at this scenario.
3. Revisit the idea of init methods, and allow such methods to have init lists themselves. For such methods, they could specify init { Property = _ } as part of the signature, and calling such a method from the constructor would count as setting the property. The method would then be required to set Property on all paths out of the method, which can include calling another init method themselves. In some ways, this can be viewed as a more concrete and integrated version of MemberNotNull for initialization, as it can replace usages of MemberNotNull on initialization methods called from constructors.

Declaring properties in property parameter lists

The record examples are somewhat verbose, and it would be nice if we could make them shorter, like positional records. This isn't just an arbitrary drive for terseness: short syntax will be essential for making discriminated unions useful. If there is no shorthand for nominal records in discriminated unions, it's likely that positional will be preferred for no other reason than brevity. We've discussed a couple of different syntax for inline property declarations:

// Syntax 1:
record Person()
    init
    {
        public string FirstName,
        public string LastName
    }
{
    public string MiddleName { get; init; } = string.Empty;
};

// Syntax 2:
record Person init
{
    public string FirstName { get; init; },
    public string LastName { get; init; }
};

Both syntax forms would declare a public init-only property, but with varying levels of brevity. We have some concerns about both forms, however:

1. This looks like a field declaration, but it declares a property. Also, how much do we allow users to specify here? readonly, new, abstract, virtual, etc?
2. This is not much shorter than just declaring the properties themselves, and could end up being very confusing if there are multiple properties followed by a regular class definition.

Everything required annotations

The original required property proposal used a keyword on the properties themselves to create a list of the required properties in a type, and this list was then inherited by every constructor. This is useful for types with multiple constructors, but we think that constructor chaining is the appropriate way to handle this scenario. A type would provide a default constructor, possibly private, that defines a single init list for the type, and then other public constructors can chain to that default constructor, removing requirements as appropriate. However, there is a more interesting scenario...

Interactions with factories

The LDM has looked several times at first-class factory methods in the language, which would allow users to use object initializers on the return of a factory method. A factory is a more interesting place to consider the everything required scenario, because it seems reasonable that a factory would want to say "you must initialize all the things in the type, except the things that I initialize for you." Our perennial example is MakeAMads(), which would return a Person with FirstName set to "Mads". Ideally, this factory wouldn't care about the rest of the properties of Person, and adding a new required property such as Color EyeColor { get; init; } should just be automatically reflected in the signature of the factory. However, since factories could potentially call one of a few different constructors on a type, or potentially return a derived type of the return type, this becomes more complicated. We looked briefly at using primary constructors as a way of describing this: a factory could say that it required everything from the primary constructor of the type, modulo whatever properties it wants to explicitly set. In this scenario, however, there likely additionally needs to be a way for factories to express the inverse as well, that users only need to set specific properties and the factory will take care of the rest. We need to do some more brainstorming around this topic, particularly as factories come better into focus.

Interation with other languages

The questions here are mainly around how far do we want to go with enabling interop. We believe there's a good story here with leaving off init { }: a type with a property parameter list in C# would be able to be inherited from in VB, and it would be analogous to inheriting and leaving off the init { } syntax in C#. With a bit of compiler work, VB should also be able to consume these types. While it's unlikely VB will actually gain support for creating types with required properties, it should be able to continue operating in the .NET ecosystem here. F# will similarly be able to make changes to support
this, though it's likely they'll go further and allow defining such types.

Property-based requirements

This proposal takes a very constructor-centric approach to expressing requirements, but depending on the shorthands we end up allowing, this could require that properties need to be duplicated multiple times for simple classes, which is something we were trying to avoid with this proposal. An alternative solution would be to allow the properties themselves to be declared "required" in some fashion, which would build up a list that would be added to all constructors. The downsides here is that we'd then need to add some syntax to allow constructors to opt-out of these requirements (copy-constructors, for example) and not pass on requirements to users.

Unsatisfiable contracts

This proposal does allow the possibility of contracts being unsatisfiable, such as if one dependency updates to add a new requirement to a protected constructor that is then not handled by an intermediate assembly. How do we want to enforce these?

Source vs binary break inconsistencies

As the proposal exists today, most additions and removals of individual properties are source-breaks only. However, if we use a modreq to indicate that the constructor has required properties, it will mean that going from no required properties to any required properties is a binary-breaking change. We need to consider going either way here: we can try again to make it a binary-break to add or remove required properties, or use the Obsolete trick we've done in previous releases to make moving from no required properties to some required properties not a binary-breaking change.

Discussed in LDM: https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-12-07.md
https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-01-11.md, with the proposal update linked below: #4209 (comment).

[HaloFour]

How does validation fit into this proposal, if at all?

[333fred]

How does validation fit into this proposal, if at all?

It doesn't. It's certainly a scenario we want to consider, but this proposal doesn't cover it.

[orthoxerox]

I will need more time to digest the whole proposal, but it looks incredibly overwrought for the primary use case: make the compiler check that multiple properties and/or fields have been initialized in the initializer. There's one question that I want to ask specifically: are there really use cases for factories returning half-baked instances that require an initializer?

[333fred]

are there really use cases for factories returning half-baked instances that require an initializer?

I think there will be, yes. Today, there are plenty of Create method that exist for various things, and the analogy to parameter-based create methods would be nominal-based create methods. Maybe that's one of the scenarios we end up cutting to simplify the proposal, but it's important to note that this proposal doesn't really even take them into account, it just leaves the door open for their eventual addition.

[ericsampson]

people have provided examples of real uses cases of these scenarios FWIW.

[markm77]

This is a nice proposal but doesn't allow a programmer to express in-place that a property's auto-default is meaningless and should never be used and that the property should always be initialised. Thus bugs will creep in because the new task of maintaining "init lists" will be imperfectly performed. Actually I think the original proposal of "required" would work well alongside (in addition to) this proposal so tooling/complier could automatically update/warn about "init lists" based on "required".

[333fred]

I do agree with this distinction, and I think it's an important one: for the simple cases, there should be a way to declare the property and requiredness together. This proposal asks the question of whether the init list should be the thing that declares the property (one of the open questions). We did take a look at inverting that, declaring requiredness on the property, and that in fact was where the original version started. We moved away from that, but after feedback from LDM in general we may explore back in that direction again to try and make the 70% case simpler.

[markm77]

Sure, understand. One idea might be to support the "required" modifier in general and for the specific case of primary constructors support an init list for property or even field auto-generation purposes. Such an init list could auto-generate fields/properties with/without "required" depending on use cases you want to capture. In this case the init list simply becomes shorthand for writing out field/property declarations in full and an extension of primary constructors to support auto-generation of non-constructor items such as "init properties".

[ericsampson]

@333fred thanks for continuing to engage on these proposals, there's a lot of discussion and points of view, but I really appreciate that you're continuing to try and find a good approach :)

[333fred]

Thank you all for giving me the feedback :). Much of what is being said here aligns well with what the LDM reaction was, namely around the simple case being too hard, so I'm glad to see that the community is mostly of the same mind as us.

[ericsampson]

I think "make the common simple and the difficult possible" is a great guideline for language features :)

[Richiban]

I hate to say this because I can see how much effort has gone into this proposal, but for me it really looks like this misses the point of required properties; that you're able to express a type by listing its properties and state that they (or some subset of them) are required without having to repeat yourself in the class definition as you do today through use of constructors.

Certainly the proposal has the advantage of playing nicely with potentially complicated type hierarchies and constructor chains, but the simple case (here's a type made up of properties and they're all required) still simply requires too much code.

I see that you've recognised this in the section on records with mention of a shorter syntax that would allow the developer to combine property and init lists, but why only recognise the need for this de-duplication in records?

[333fred]

I see that you've recognised this in the section on records with mention of a shorter syntax that would allow the developer to combine property and init lists, but why only recognise the need for this de-duplication in records?

The intent was not just records, to be clear. Rather, the intent was to align with primary constructors in general. If primary constructors in regular classes allow you to declare fields and/or properties in line, init lists should as well analogously.

[Richiban]

Ahh, I see! Thanks for clearing that up

[rbwhitaker]

I'm not sure I see huge benefits to this over just making the constructor take those items as parameters. The constructor's role in the past has been to ensure the object is initialized to a legitimate starting state. If a property needs to be initialized, just put it in the constructor. Let the non-essential properties be set in object-initializer syntax, but the essential ones come through the constructor.

I'll admit there are probably use cases for this anyway but do keep in mind that every new feature complicates the language. The benefits of new language features should be clear and significant in order to be added to the language. In my opinion, this adds complexity at a much higher rate than it adds value.

[alrz]

I'm not sure I see huge benefits to this over just making the constructor take those items as parameters. The constructor's role in the past has been to ensure the object is initialized to a legitimate starting state.

I second this. The notation of "required properties" is at best a code smell IMO. You should use constructors for that.

Maybe you could use "direct constructor parameters" or "primary constructors" feature to make it less verbose.

I think the main ask in the previous proposal was to just move the nullable warnings to the call-site rather than the declaration-site.

edit: If you really want the notation of "required properties" it can be easily implemented as an analyzer e.g. using RequiredAttribute.

[EnCey]

I second this. The notation of "required properties" is at best a code smell IMO. You should use constructors for that.

I politely disagree with this statement. If we take Data Transfer Objects as an example, it is not difficult to come up with example classes that contain "many" properties

Today, if I want to make it clear that some or all of these properties are required, I must create a constructor with n parameters followed by n assignments of these parameters to the respective property.
This is the first issue, the verbosity and maintenance overhead: adding new properties requires extending constructors.

The second issue is the call site: it is not fun to use constructors with 5+ or 10+ parameters. The greatest problem is that you don't see which property will receive the constructor argument you are passing.
The object initializer syntax is much clearer for this use case, as you explicitly state each property name and assign it a value. It also doesn't require any "constructor maintenance" when new properties are added. The only downside is that you can't enforce property initialization, hence these proposals.

I realize there probably won't be many real-life examples of DTOs with large constructors as I describe here, but I believe that's because it is such an eye sore and maintenance toll that people rather rely on object initializers and just "take the risk" of having uninitialized properties.

[jods4]

As I said in #3630 (comment) solving nullable initialization is a big use-case for this and the design presented here is really not appealing in that regard.

I get that if you want to require initialisation of any property, .e.g an int, you'll need some kind of explicit syntax.
But for a string? no explicit syntax should be needed. It has no acceptable default value, so it implicitly requires initialization.

This design is cute with 2 properties. In our real code we have real classes that may have 30+ properties (think mapping large DB entities). Many of which might be nullable refs (e.g. string?) . I don't see myself repeating a list of 30 names in a code location different than property declaration, esp. since those classes typically have no ctor.

This feels like Java checked exceptions lists more than C# :(

[foxesknow]

I'm surprised nobody has told you to write an analyzer for this yet...

[alrz]

I think I did #4209 (reply in thread) 🙂

It would be very straightforward too. RequiredAttribute already exists.

I think as far as the compiler concerns, it's not a correctness issue except for nullables. Other than that I believe using attribues+analyzers is a superior solution compared to any kind of syntax and in particular, the one proposed here is too much IMO.

[foxesknow]

I tend to see it the other way. Depending on analyzers seems like a weak way to add a rule that can just be circumvented by disabling the analyzer. The language should have first-class support for features like this.

[foxesknow]

If a property is required then it should go into the constructor parameter list. The whole point of constructors is to ensure the instance is initialized to a correct state at the point of creation.

Why is another syntax needed?

[foxesknow]

What problem are constructors causing you?

[Richiban]

The crazy amount of repetition needed to express a simple concept. If I have a class for carrying data, such as a model, I can define properties and now can specify init on each one, but to say that each property is required can only be done with a constructor which will triple the size of the class (in lines of code).

Since I spend an awful lot of time reading code rather than writing it and--come to think of it--a lot of that reading is done outside of an IDE. For example, this model:

public class MerchantOrderPostModel
    {
        public long Id { get; }
        public string ResourceUri { get; }
        public DateTimeOffset CreatedOn { get; }
        public MerchantPostModel Merchant { get; }
        public ItemPostModel[] Items { get; }
        public ShippingSpeedPostModel ShippingSpeed { get; }
        public decimal ShippingCost { get; }
        public decimal FinalPrice { get; }
        public decimal ProductPrice { get; }
        public decimal Discount { get; }
        public decimal ShippingAmount { get; }
        public int ItemCount { get; }
        public ConsignmentStatusPostModel Status { get; }
   }

Must be turned into:

    public class MerchantOrderPostModel
    {
        public MerchantOrderPostModel(
            DateTimeOffset createdOn,
            decimal discount,
            decimal finalPrice,
            long id,
            int itemCount,
            MerchantPostModel merchant,
            decimal productPrice,
            string resourceUri,
            decimal shippingAmount,
            decimal shippingCost,
            ShippingSpeedPostModel shippingSpeed,
            ConsignmentStatusPostModel status)
        {
            CreatedOn = createdOn;
            Discount = discount;
            FinalPrice = finalPrice;
            Id = id;
            ItemCount = itemCount;
            Merchant = merchant;
            ProductPrice = productPrice;
            ResourceUri = resourceUri;
            ShippingAmount = shippingAmount;
            ShippingCost = shippingCost;
            ShippingSpeed = shippingSpeed;
            Status = status;
        }

        public long Id { get; }
        public string ResourceUri { get; }
        public DateTimeOffset CreatedOn { get; }
        public MerchantPostModel Merchant { get; }
        public ItemPostModel[] Items { get; }
        public ShippingSpeedPostModel ShippingSpeed { get; }
        public decimal ShippingCost { get; }
        public decimal FinalPrice { get; }
        public decimal ProductPrice { get; }
        public decimal Discount { get; }
        public decimal ShippingAmount { get; }
        public int ItemCount { get; }
        public ConsignmentStatusPostModel Status { get; }
    }

You can see the size of the file has exploded, the constructor is now incredibly unwieldy if we want to introduce things like optionality or default values, the signal/noise ratio has degraded significantly and, what's more, it's an excellent hiding place for bugs.

In this example, the developer has made a simple mistake and one of the properties is not initialised in the constructor. Can you spot it?

[Joe4evr]

And don't forget the case of deserializing data into model classes with a framework that can't handle parameterful constructors.

[orthoxerox]

And don't forget that if you inherit from this class you have to repeat everything twice in the derived class' constructor as well.

[markm77]

Basically to me this feature is firstly about completing the design of object initialisers which are great for public properties (see my comment here). But regardless of our persuasion re. constructors vs object initialisers I notice people are using object initialisers for "required" properties anyway creating bugs.

And secondly this feature allows us to solve the problem of unwanted default values which are a major source of bugs. This is most readily seen in the case of non-nullable reference types where the default value is actually invalid but there are many times when a default value is known to be meaningless and should never be used. "Required" allows the programmer to express this and reduces bugs.

[YairHalberstadt]

How will this be stored in metadata? It's important this is simple (i.e. not like NRTs encoding) since IOC containers will need to make use of this information.

[333fred]

We're still working through the exact way to encode it. I'm not certain exactly how simple we can make this, it's likely that we'll want a helper reflection API to handle that for IOC and DI scenarios.

[canton7]

An alternative solution would be to allow the properties themselves to be declared "required" in some fashion

I do think that this is more in line with what I'd want to use. By default, required properties would always be required, but constructors could opt-out using e.g. an attribute. You could add a warning/error if a constructor opts-out without actually setting the property.

At least for me, the majority use-case would be an object where all required properties would need to be set by the caller, and only in very rare cases would a required property be set by a constructor. Repeating the properties' names in these cases feels very noisy.

class Person
{
    public string FirstName { get; required init; }
    public string LastName { get; required init; }

    public Person() { }

    [Initializes(nameof(FirstName), nameof(LastName))]
    public Person(Person other)
    {
        FirstName = other.FirstName;
        LastName = other.LastName;
    }

    [Initializes(nameof(FirstName))]
    public Person(string firstName)
    {
        FirstName = firstName;
    }
}

If you suspect that the majority of constructors which initialize properties would initialize them all, then allow e.g.:

    [InitializesAll]
    public Person(Person other)
    {
        FirstName = other.FirstName;
        LastName = other.LastName;
    }

Constructor chaining comes naturally:

class Rectangle
{
    public int Length { get; required init; }
    public int Width { get; required init; }
}

class Square : Rectangle
{
    [Initializes(nameof(Length), nameof(Width))]
    public Square(int side)
    {
        Length = side;
        Width = side;
    }

    [Initializes(nameof(Length), nameof(Width))]
    public Square(int side)
    {
        var transformed = transformSideLength(side);
        Length = transformed;
        Width = transformed;

        static void transformSideLength(int side) { ... }
    }
}

There's a decision to be made on whether chained constructors automatically inherit the Initializes attributes of the constructors they call.

For bonus points, there's a route through to factories:

[Uninitialized(nameof(Person.LastName))]
public static Person CreateAMads()
{
    return new Person() { FirstName = "Mads" };
}

The compiler enforces that the method CreateAMads initializes all properties of its return value, except those specified by Uninitialized. Properties specified by Uninitialized must be initialized by the caller.

Implementation-wise, this might mean a modreq on all construtors which don't initialize all properties, or you could potentially tie it into the validation discussion (which is happening wrt records) and fall back to a validator-generated runtime exception if a downlevel compiler / other language / ioc container doesn't set all required properties.

---

Obviously, all attribute names, required set, etc etc are made up -- I don't want to start a discussion on naming. You could use an attribute instead of required set, or a keyword instead of Initializes: that's not the point.

I've probably missed some vital point which shoots this down, as well...

[spydacarnage]

I do think that this is more in line with what I'd want to use. By default, required properties would always be required, but constructors could opt-out using e.g. an attribute. You could add a warning/error if a constructor opts-out without actually setting the property.

Is this attribute even necessary? The tooling already knows which fields/properties aren't set at the end of a constructor, so can't it also determine which required properties are set?

Any required properties which then aren't set, either by the constructor, or by an init block, are reported to the call site.

I'm not well versed in how the compiler works, so apologies if I'm missing something huge, but that would be how I'd like to see it, tbh.

[canton7]

Yeah, the compiler could automatically insert any such attributes. I was thinking that it would probably form part of the signature of the constructor, as changing it would have implications for consumers, but it could also be automatically determined. That's a fairly minor part of it I think, though.

[333fred]

We took a look at systems that automatically infer lists, and rejected them. These lists are public apis, and C# has never been about implicit public api details. Any accidental change in the body of a constructor could cause a source breaking change for consumers of the type unintentionally, which is not something we're interested in enabling.

[canton7]

Yep, I'm on board with that.

I'm still personally in favour of the properties themselves specifying requiredness though, and constructors explicitly opting to make them non-required, rather than the other way around. Yes it means naming the property 3 times in the less-usual cases, but it means naming it only once in the more common cases. It also means less new syntax, which I think is important. This fits with:

make the easy things easy, and the hard things possible

You could also get IDE support for updating the records of which required properties a ctor populates.

[gulshan]

For a DTO class, I just want to put names and types of the properties, and optionally default values. Whether a property is required or not should be inferred, based on nullability of the types and default values. And these properties should be immutable and public by default. I can do it in very few languages. TypeScript and Kotlin are closest to what I want. I don't know if it will ever be possible in C#.

[333fred]

I don't know if it will ever be possible in C#.

Unfortunately, since properties have been optional in C# since day one, I don't think it will be. One of the quotes of the day was in reference to this: if I had a time machine, I'd change everything about initialization in C#.

[xSke]

To me, the primary purpose of record types and init properties is these kinds of DTOs - big bag of properties, some required, some optional. Too many properties for positional constructors to be practical (once you go over five it gets messy). Any proposal to solve this issue that doesn't address this to-me-incredibly-fundamental use case is dead in the water, IMO. I was disappointed when I saw C# 9 seemed to neglect this use case at all..

What I want to be able to write is something like:

public record MyThing {
    public string Foo { get; required init; }
    public string Bar { get; required init; }
    public int Baz { get; required init; }
}

var thing = new MyThing {
    Foo = "foo",
    Bar = "bar",
    // and then get a compiler error if I leave `Baz` out, instead of just giving it a likely-nonsense default value
}

[ericsampson]

I also really like the idea of a new modifier, whether it's something like required init or initreqd or whatever. But that concept is what makes the most sense to me as being easy to understand and use (pragmatic).

[TonyValenti]

@xSke This is the way I want requires properties to look and work!
Clean, simple, and to the point!

[MgSam]

What are the benefits of object initialization syntax?

• Can set properties in any order
• Can set properties by name so it's self-documenting
• No properties are required

What are the benefits of constructor parameter initialization?

• Can set parameters in any order (named parameters)
• Can set parameters by name (named parameters)
• You can validate parameters
• Parameter are required unless explicitly opted not to be via defaults

As far as I can tell, the only real feature difference between object initialization and constructors today is in fact the requiredness issue. For some reason, the LDT seems to "forget" about named parameters in these proposals about fixing/bypassing constructors. Named parameters are perfectly legitimate and give most of the same benefits attributed to object-initialization syntax.

IMO, this proposal seems to be giving us duplicative functionality that doesn't actually save much code because you're still repeating yourself by typing every property name again.

[333fred]

because you're still repeating yourself by typing every property name again.

This is the part that I've heard a lot in this thread, and we'll be working on revisions to reduce this. You do save a number of repetitions already when you consider type hierarchies (you have to repeat parameters across every constructor, whereas this proposal would allow you to inherit the list and not have to repeat anything), but the simple case can definitely be simpler. One of the open questions proposes that the init list could declare properties, but perhaps we can come up with a way of creating that list by applying a modifier to properties.

[333fred]

Additionally, you mention "No properties are required" as a benefit of init lists. We don't see that as a benefit, which is why this proposal exists. 🙂

[TonyValenti]

It would be great if a derived class could auto-implement all the base constructors of no additional constructors were specified.

It would also be really nice if you could just specify the new parameters instead of the entire chain again.

[acaly]

I am also curious whether the LDT is interested in init-methods (i.e., methods that can only be called in initializer, related issues: dotnet/roslyn#5365, #4218).

Some points I can think of:

1. Can constructors and factory methods specify init-methods that must be called (at least once) in the initializer (i.e., required init-methods)?
2. Can init-methods consume required properties and other required init-methods ?
3. If a init-method sets some required properties with protected or even private modifier specified by, say, constructor A, can another constructor B using constructor A leave those required properties uninitialized and instead ask user of the class to call that init-methods to initialize them?

[333fred]

We discussed required properties again in LDM today, with the following proposal as an extension to the original proposal in this issue. As we're going to keep iterating on this, I'm not going to fully update the original proposal in this thread or in the championed issue thread until we come to a better consensus on the form we want this to take. See also the notes from today's LDM: https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-01-11.md.

Required Properties Simple Base Syntax

Last time we talked about required properties, we came to the conclusion that while we like the principle, and we liked many aspects of the proposal, we felt it was too complicated for the simple case. Much of the community feedback to that proposal falls into a similar vein. To try and remedy this, we've gone back and taken another look at allowing requiredness to be stated on the property, coming to a version that I've been calling exploded require lists.

Almost all of the syntax from the previous proposal still applies here: this extension is simply adding a new sugar to make the simple cases easier to express. It also changes the modifier from init to require, after feedback that init was too close to init properties and confusing. Let's walk through some examples of what this looks like.

require modifier

We introduce a new require modifier, allowed on properties and on fields, like so:

class Person1
{
    // Implies a public parameterless constructor that requires FirstName and LastName
    // must be set
    public require string FirstName { get; init; }
    public require string LastName { get; init; }
}

When compiling a type, we look at all the fields and properties that are marked require, and put them into a default require list. If no constructor is provided and there are required fields or properties, the implicit parameterless constructor is automatically marked require with that list of properties.

You can also define such a constructor manually. We allow the require clause to be default, which means use the list of all properties and fields that are marked required.

class Person2
{
    public require string FirstName { get; init; }
    public require string LastName { get; init; }

    // Explicitly use the "default" requirement list for this explicit constructor. This is equivalent
    // to the constructor synthesized for Person1
    public Person2() require default { }
}

class Person3
{
    public string FirstName { get; init; }
    public string LastName { get; init; }

    // Explicitly declare the requirements of the parameterless constructor. This is equivalent to Person1
    // or Person2, and is the original syntax we had last time.
    public Person3() require { FirstName, LastName }
    {
    }
}

Traditional constructors mean the same thing that they do today: if there's no require clause, then it has no requirements. We will likely want to make the Person3 scenario below an error, as it has FirstName and LastName in the default require list but does not initialize them in the constructor or pass the requirement onto the construction location.

class Person4
{
    public require string FirstName { get; init; }
    public require string LastName { get; init; }

    // Not an implicit constructor and has no require clause, so no requirements are exported. There are
    // required properties in the type so not initializing them in this constructor is an error.
    public Person4() { }
}

Implicit constructors automatically inherit require clauses from their base types, and add their own requirements to the list.

abstract class Person5
{
    // Implies a public parameterless constructor that requires FirstName and LastName
    // must be set
    public require string FirstName { get; init; }
    public require string LastName { get; init; }
}

class JustAPerson5 : Person5
{
    // Implicit public constructor inherits the require class from the base type and adds
    // nothing to it.
}

class Student5 : Person5
{
    // Automatic parameterless constructor requires everything from the base as well as requiring
    // ID to be initialized at construction as requiring.
    public require string ID { get; init; }
}

The explicit version looks just like it did in the last proposal:

abstract class Person6
{
    // Implies a public parameterless constructor that requires FirstName and LastName
    // must be set
    public require string FirstName { get; init; }
    public require string LastName { get; init; }

    public Person6() require { FirstName, LastName }
    {
    }
}

class JustAPerson6 : Person6
{
    // The require clause must be specified after the base call to make this a require constructor, or there'll be
    // an error about not initializing the required properties from the base.
    public JustAPerson() : base() require {}
    {
    }
}

class Student6 : Person6
{
    public require string ID { get; init; }

    // Inherit all requirements from the base class and add ID.
    public Student6() : base() require { ID }
    {
    }
}

[333fred]

You have to provide an object initializer that initializes the properties. This is unchanged from the original proposal.

Ok, so for example :

class C
{
  public require int P1 { get; init; }
  public require int P2 { get; init; }

  public C (int p1) require P2
  {
    P1 = p1;
  }
}

and then new C(1) { P2 = 3 } is valid ?

That syntax is valid today. The difference is that it's required with the proposal.

[333fred]

Thanks Fred.

Is there still interest/discussion on the “first-class factory methods” concept?

Yes, but beyond making sure that we keep them in mind, it's an orthogonal feature.

[markm77]

Really like require on properties and fields.

This means we can solve a host of issues/potential bugs by simply making sure each property/field either has (a) a usable, meaningful default or (b) require. The programmer can express his/her intention simply and concisely at the right time and then the compiler/tooling can do the heavy lifting to ensure rigorous, safe code and correct re-factorings. Nice!

Regarding "require lists". These seem to essentially be there to allow constructors to have customised requirements and I see there has been an interesting discussion in the LDM. Seems you are leaning towards simplified customisation possibilities with minimum boilerplate. Which again sounds great.

Thanks for seriously considering all the feedback; I'm sure you'll produce a great feature from all this which will seriously improve C#.

[markm77]

PS: you might also want to consider making it an error to specify require and an explicit default to make clear to programmers the explicit default will never be used*. This is an optimisation similar to possibly making require implicit for non-nullable reference types without an explicit default (as mentioned above by @jods4 ).

* I realise there is a complication if a constructor has reduced requirements due to its "require list".... for me though that shows potential issues with too much flexibility. I would prefer that "require lists" were additive rather than subtractive (a la LDM notes) to ensure property/field-level require is absolute and checks like the one suggested for redundant explicit defaults could be used.

[markm77]

Another point to add about subtractive "require lists" for constructors (those which reduce requirements compared to the default require list implied by require properties/fields). These don't seem very natural or useful to me as you could e.g. simply assign a default value inside the constructor body to cancel the requirement for initialisation. If necessary all require properties/fields could be assigned defaults within the constructor body to e.g. ensure nothing further is required to be initialised in an object initialiser. This seems a more natural way to "cancel" requirements (has the benefit of ensuring all properties/fields have legit values).

Whereas additive "require lists" for constructors (those which add requirements compared to the default require list implied by require properties/fields) make sense as it may be the case that for certain uses of a class the normal default of a field/property is no longer meaningful. The user of the class needs to specify a value and this is a mechanism to enlist the help of the compiler in ensuring this.

[333fred]

LDM looked at a new version of this spec today (3/3/2021, read that month-date-year or day-month-year, as you please). The spec is PR here, and while there is still some design work and refinement to be done, the overall shape is in a good state now.

[333fred]

I can't say with certainty. This will be the next feature I work on after the improved interpolated strings work, but whether that will be in time for C# 10, I can't say for certain.

[TonyValenti]

@333fred I believe that this will be one of the single best improvements to C# in a long, long time and I am super excited about it.

When you build it, it would be great if you can persist the "required"ness in a way that is easily retrieval by library authors. It would also be great if different constructors could provide "feedback" on required members that don't need to be set because the specific constructor overload sets them.

In our use case, we use a DI framework (AutoFac) and have a series of base classes that we often derive from. We have 300+ classes that have a constructor whose sole purpose is to call a base constructor.

It would be so nice if I could just make the base properties required and eliminate 300+ boilerplate constructors. (I know I'd need to write an autofac plugin to set the required properties but this would be well worth it).

I really hope your current project wraps up soon!

[TonyValenti]

@333fred I just reread the proposed spec and something stood out to me:
I think that the "init" clause of a constructor should be automatic.

Today, when you have nullable enabled, you get a warning when your constructor fails to set a non-nullable object property to an instance of an object.

I think that "required" properties should behave similarly. If a required property is set via a constructor, the constructor should automatically advertise that the property is no longer required - no constructor init clause required.

[333fred]

@333fred I just reread the proposed spec and something stood out to me:
I think that the "init" clause of a constructor should be automatic.

Today, when you have nullable enabled, you get a warning when your constructor fails to set a non-nullable object property to an instance of an object.

I think that "required" properties should behave similarly. If a required property is set via a constructor, the constructor should automatically advertise that the property is no longer required - no constructor init clause required.

See #4209 (reply in thread).

[Duranom]

How much will the changes be checked against current existing solutions and how it will feel / behave with them? For example with EF, (de)serializations or in DTO models like in a ASP Core API as argument from parameters (from Param or Body) or gRPC.
I know the current idea is to let Activator.CreateInstance(typeof(C)) bypass it but that sounds a dangerous... or to let a (private?) empty constructor exist which can have init required! {} but that looks more like a hack and takes away the possibility of having an empty constructor if you needed if for other reasons.
(Aside from that perhaps code should be changed than with more accommodating patterns and design)