Added: LDM Notes for January 5th, 2022

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-01-05.md

Agenda

1. Required Members

[theunrepentantgeek]

Using a single RequiredMembersAttribute that's only on the containing type would introduce additional complexity for code using Reflection - instead of having all the relevant metadata directly available from a PropertyInfo instance, there'll need to be a separate (and complex) lookup.

With a RequiredMemberAttribute on each property, access might be as simple as this:

var isRequired = propertyInfo.GetCustomAttribute<RequiredMemberAttribute>(true) is not null;

If the information is only available via a RequiredMembersAttribute on the declaring type, things would be more complicated. Maybe it would look like this:

var isRequired = 
    propertyInfo.DeclaringType.GetCustomAttribute<RequiredMembersAttribute>(false)
        .RequiredMembers.Any(m => m.Name == propertyInfo.Name);

Though, as I wrote the above code I realised that I haven't handled inheritance - so the above would need to be modified to walk up the inheritance chain too.

We think the version with a single attribute is slightly more attractive, so we'll go with that one

Might the complexity of use via reflection push the balance across to preferring multiple attributes?

Bonus question: If an interface declares a required property, would the metadata for classes or structs implementing that interfaced include the required'ness of the property? Or would reflection code need to walk the interface metadata too?

[RikkiGibson]

It feels like similar problems exist with reflection and nullable. Discussed in dotnet/runtime#29723. Perhaps with the existing design, the PropertyInfo/FieldInfo types could have an "IsRequired" API added or something similar and that would provide a satisfactory experience.

[333fred]

Agreed with Rikki. It certainly is a consideration, but I think reflection should have first-class support for an IsRequired property, regardless of what the metadata representation is.

If an interface declares a required property

It cannot.

[TonyValenti]

I think that the required members attribute should be applied to constructors, not the type or member. This would allow a constructor to initialize a member and make it no longer required.

[333fred]

I replied to you with a longer explanation here. TLDR: maybe that will be supported in the future, and the encoding scheme we would use then will work with this just fine.

[MrJul]

(was meant as a reply to @theunrepentantgeek's post)

I agree, having the attribute on each member has the following pros:

• As mentioned, the IsRequired reflection code (which will probably be part of the runtime as discussed above) doesn't have to recreate exactly the same lookup rules as C#, which may vary in the future. For example, if C# 12 wants to allow an overridden member to remove the required-ness (a scenario I'd personally like to see even if it isn't part of the current proposal, I can imagine a derived class filling a required base member itself, effectively making it not required anymore for the consumers), all the compiler has to do regarding metadata is to stop emitting the attribute on the member. In the single class attribute model, new metadata has to be designed (with explicit member exclusion?), the runtime and all dependent tools modified with the same logic, and a time machine is probably needed to patch the older compilers. Those changes are costly/breaking enough to basically close the design from any future modifications.
• External tools that modify metadata don't have to understand that the class attribute is a special one containing member names that should be handled accordingly.
• It isn't ambiguous. It's neither valid C# nor CLS compliant, but ECMA-335 allows the same name for different members, as long as they're of different kinds: having a field A and a property A is perfectly valid. An unlikely scenario, but still one that should be handled specially in the single class attribute case instead of flowing naturally from the member definitions.

[jnm2]

Field-like events are already emitted as a pair of members with the exact same name: the event itself, and a private field.

[333fred]

These are good points, and I'll give it a think. Ultimately, I'm not particularly attached to any one emit strategy, beyond having started working on the existing one.

[davidroth]

Is the "position" of the required modifier already set in stone or will there be a discussion whether it makes sense placing the required modifier before the "set" keyword?

E.x.

  public virtual required int Prop2 { get; set; }
  // vs:
  public virtual int Prop2 { get; required set; }

Personal I'd strongly prefer the latter.

[spydacarnage]

As this feature is called RequiredMembers, that implies that at some point, even if not immediately, this feature will include required fields.
I'd prefer to see consistency in the placement of the required keyword between all members, and obviously only properties have the init/set option.

[dlebansais]

I'm eagerly waiting for this new feature that should have a huge (hopefully positive) impact on my code.

It occurred to me that adding required members might have side-effects on custom deserializers.

Before, when deserializing, you could do this:

1. Create the instance.
2. Deserialize other objects.
3. Assign instance members to these deserialized objects.

Now the order has to be strictly members first, instance last, and I'm not sure one can create the instance and assign members in separate operations.

[Unknown6656]

Hahahaha, that picture had me falling off my chair. Good one.

[TonyValenti]

I think that the required members attribute should be specified on each constructor. This would allow constructors to determine whether a member is required or not. For example, I might have a constructor that sets 3 required properties using a single parameter. Please reconsider.

[Unknown6656]

@TonyValenti I very much like your idea.

[TonyValenti]

@Unknown6656 Thanks! This also solves the problem of what happens on overrides and how to make a required property no longer required (just set it in the constructor).

This would also be really useful for DI frameworks like AutoFac because they could interrogate a selected constructor to find out what additional properties need to be set post-construction.

I really hope the team reconsiders the placement of the attribute. Placing it on the type directly would really box the feature in.

[333fred]

I think that the required members attribute should be specified on each constructor. This would allow constructors to determine whether a member is required or not. For example, I might have a constructor that sets 3 required properties using a single parameter. Please reconsider.

The original design that I brought to LDM took a constructor-centric approach to this, allowing individual constructors to require members or not require members as it saw fit. We stepped away from this for a few reasons:

1. We don't want users with multiple constructors to be forced to specify the full list of required members at every constructor.
2. We don't think that any implicit determination of what should or should not be required is ok. This is a public API, and modification of the public API should be an explicit action taken in source, not inferred from whether a property is set in the constructor body.

Points 1 and 2 meant that we needed a way to create a list of all required members in a type, that all constructors could inherit automatically: thus, the required keyword, which creates the types list of required members. We then came up with the init-clause syntax (see the section in this version of the proposal). LDM review decided that, at least for now, this is too complicated. That's not saying that future versions of the language can't add something like this: if we see use cases blocked by the more restrictive set of rules, then we can look at them. However, at least for the initial version, we'd rather keep focus on the core scenario. We don't think that we're boxing in or out those future scenarios: they'll still be possible with the right set of attributes. They're just not what we're looking at right now.

[HaloFour]

One of our desires for this feature is that removing required members is not a binary breaking change.

What about the inverse? Is adding a required member to a type that doesn't have one a binary breaking change? Or adding a new required member to a type that already has required members? If not, what is to prevent existing consumers from now violating the contract?

[TonyValenti]

Also, regarding accessibility of members, I think that required members should be able to be protected or private.
A private required member must be set in a constructor of the current type and a protected member must be set either in the base constructor or a derived constructor.

[333fred]

There's nothing saying that we can't add this in a future version of the language. However, since we aren't planning on individual-constructor modification of required member lists beyond an "opt this constructor out of all requirements", this isn't really doable at the moment.

[TonyValenti]

In that case, RequiredMembersAttribute should belong on the constructors and not the types. This would allow you to only have to query one location to determine what additional members are required for that construction. If a constructor has requirements, it should have an attribute like [RequiredMembers(nameof(Property1), nameof(Property2))] and if it has no additional requirements, just [RequiredMembers()]. Also, in terms of storing metadata, you might consider having an AddRequiredMembersAttribute and a RemoveRequiredMembersAttribute.

I agree with the LDM that the original spec of the init(....) clause needed work, but I still like the concept (although I do prefer inference). I felt like it should be a special "method", placeable only as the last line in a constructor. ie:

public class C
{
    public required int Prop1 { get; init; }
    public required int Prop2 { get; init; }

    // Advertises that just Prop1 is required.
    public C()
    {
        Prop2 = 2;
        Console.WriteLine($"Prop2 is {Prop2}")

       init(Prop2);
    }
}

[333fred]

In that case, RequiredMembersAttribute should belong on the constructors and not the types.

Remember that one of the goals of the feature is to avoid duplicating information across multiple types in the hierarchy. If I depend on Library A and B, and B subclasses something from A, then updates to A should be able to add new required properties that get surfaced to me in library C, without having to update library B. In order to accomplish this, we need one of two things:

1. Encode required members on a type-level, that can be recursively gathered. This is the current approach.
2. Encode the base constructor being called by the derived type, so that can be recursively gathered. It is important that this be done for all constructors, not just the ones that currently expose required members, because a future update could add required members to a base type where none existed. This is pretty untenable: that's a huge amount of bloat and encodes implementation details in the public signature of the constructor.

[TonyValenti]

The base constructor doesn't need to be encoded because The recursive gathering could be gathered at compile time.

I can't imagine many objects expressing hundreds (or even tens) of required properties. I would be Completely fine if each constructor was fully decorated with the names of all required members for all base constructors. If you were to average 5 required properties on a class and estimate 10 characters per member name, that is only 50 bytes. I would certainly be willing to stomach a lot more than that to be able to cut out all my boilerplate constructor code.

And it makes the feature so, so, so much more useful.

[333fred]

I would be Completely fine if each constructor was fully decorated with the names of all required members for all base constructors.

I get it. However, the motivation for the feature is explicitly that this not be the encoding scheme. We already have a great way of duplicating required parameters across all levels of the type hierarchy: parameters. Our goal with required members is to not do this, and instead gather requirements recursively. It's not about the size of the list, it's about the feature set we are looking to enable.