Added: LDM Notes for January 11th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-01-11.md

Agenda

• Required properties simple form

[huoyaoyuan]

Interesting thinking:

If a member is definitely assigned in a constructor, then it can be inferred as not required for that constructor. However, this also means that changing implementation of a constructor can accidentally break it's public contract.

[erikhermansson79]

If I accidentally removed the initialization of a required property I would like my code to break.

But when I initialized the property in the constuctor wasn't I removing the requiredness from the public contract? And by removing the initialization do I really break the contract or am I changing it?

[333fred]

And by removing the initialization do I really break the contract or am I changing it?

If things are inferred, then yes, your really broke the contract by changing it. It's equivalent to adding a new parameter to a method.

[erikhermansson79]

Yes, of course you are right. The contract is changed and broken. I was thinking more about the intention. Sometimes you want to or have to change the contract, even if that breaks some code. At least this feature will help me find the places that are broken.

I think I would like to have the option to use an explicit property list or the list being inferred implicitly depending on what type of code I'm writing. Or maybe the explicit list can be generated by VS.

Maybe you can reuse the "implicit" keyword when opting in to inferring the list.

[333fred]

Or maybe the explicit list can be generated by VS

Certainly, I would support tooling to help with this. But I do not think that inferred contracts are a good idea in any fashion.

[huoyaoyuan]

Required properties should have a straight metadata representation so that dependency injection frameworks can support them easily.

[YairHalberstadt]

I agree with the assessment that it should be possible to mark a property as required, and then if a constructor sets that property opt out of requiredness.

However I think given that in the 90-99% use case there will only be one constructor, adding new language syntax for this feels a bit heavy, especially as the suggested language syntax isn't the most elegant.

Instead either inferring it (as @huoyaoyuan suggests), or using a [SetsRequiredProperty(nameof(myproperty))] attribute would be better in this case.

Attribute I think offer a lot more flexibility than special syntax, as adding new well known attributes such as [RequiresNone] or [FactoryMethod] to extend this feature is much cheaper than adding new syntax.

[YairHalberstadt]

So essentially I would really like to think about how easily we can get data on this.

Specifically:

1. How many cases would there be only one constructor
2. How many cases would there be 2 constructors, 1 of which sets all required properties.
3. How many cases require something more complex.

Obviously it's difficult to get data on how a feature that doesn't exist would be used, but I think it would be great to highlight examples in Roslyn where you think this feature is likely to be used,and would require more complex handling?

[333fred]

I think it would be great to highlight examples in Roslyn where you think this feature is likely to be used,and would require more complex handling?

Rewriting would likely be more work than we'd want to take on, but if we were to write the BoundNodes today, we'd use it. Look at all the special constructors we have in Constructors.cs.

[theunrepentantgeek]

I know that one person's anecdote doesn't substitute for solid data @YairHalberstadt, but I've worked on multiple projects where many classes would have multiple constructors and where required properties would be spectacularly useful.

Off the top of my head, I can think of three broad categories of use from those projects:

• Data transfer objects - I'd now write them using record syntax; all had a parameterless constructor to allow for deserialization (via WCF) as well as a copy/clone constructor
• Server side domain objects - all had a parameterless constructor as required by NHibernate, but almost all also had at least one (if not many) other constructors; required properties would allow considerable simplification, but wouldn't allow removal of all.
• Client side domain objects - all had parameterless constructor to allow for deserialization, as well as copy/clone constructors to allow the UX (written in WPF) to work on copies

[YairHalberstadt]

all had parameterless constructor to allow for deserialization, as well as copy/clone constructors

That would require a way to say all required properties are set by a constructor, but wouldn't require a way to control it on a property by property level.

[qrli]

My explanation would be based on app vs library development.

• If you are an app developer, single constructor will be the common case, especially with better refactor tools to clean up unused code.
• If you are a library developer, you need to serve different usage patterns, and you need to keep old overloads for backward compatibility. Then the percentage of multiple constructor case will surely be much higher.

And for required property feature, the major consumer would be library developers, to communicate their intention. While for app developers, the knowledge is either in yourself or within your team, thus not as important as for libraries.

In this sense, I agree with @333fred in that inferring is not a good idea. The intention should be clearly expressed.

[MgSam]

I still say this whole avenue is a mistake. There already is a way of making properties required - put them in the constructor parameters. We don't need all this additional complexity added to the language for yet another way of doing things we can already do.

[huoyaoyuan]

Well, in theory, constructor parameters + named arguments can be used just like required properties, they are just not comfortable enough. You still have to duplicate them in constructor parameter, property and the assignment statement.

Given this pattern is extremely popular, it worth some improvement.

[theunrepentantgeek]

Explicit constructor parameters works just fine until you have more than a few, and things really get ugly when inheritance is involved.

The proposal for required priorities isn't random, it's intended to address an area of real pain - an area where devs regularly make mistakes and introduce bugs.

If you haven't already done so, @MgSam, it would be worth reading more about the history of the idea.

[MgSam]

@theunrepentantgeek
They work just fine when you have more than a few. And you can even supply them in any order you want.

class Foo {
    public Foo(string a, int b, double c, short d, DateTime e, string f) { }
}

new Foo(e: new DateTime(2000, 01, 01), b: 1, a: "bar",  c: 2.0, d: 3, f: "baz");

I think you're making the same mistake the LDT continues to make, which is to forget that named parameters exist and are extremely useful.

The inheritance problem is orthogonal in my view. The not-quite-a-proposal that was floated several years ago by Mads of doing something like this is worth exploring further: :

//(Syntax might be wrong, it's been a while since I saw the notes that proposed this)
class Foo {
    public Foo(int a, int b, int c) { }
}

class Bar : Foo {
    public Bar(..., int d) : base(...) { }
}

I felt required properties bordered on being reasonable when the proposal was for a single keyword you would use to decorate the property declaration. Now that its evolved into this monstrosity of a second list on constructors; it is overly verbose, duplicative, and the wrong path, IMO.

The LDT used to have a philosophy that all proposed features start at -1000 points and need to make up that deficit in order to be considered for inclusion in the language. I can't see this one getting anywhere close to that bar.

[HaloFour]

@MgSam

I think you're making the same mistake the LDT continues to make, which is to forget that named parameters exist and are extremely useful.

No, they're asserting that named parameters are brittle due to the required ordering of the parameters and that evolving said types is cumbersome due to having to continually add new constructor overloads. They've explicitly stated multiple times that they want to avoid both of those issues.

[jnm2]

I think @MgSam meant named arguments which is a call site feature, but named arguments don't help library developers because library developers can't enforce that named arguments are always used, and it's not a thing people generally expect to do.

[spydacarnage]

@theunrepentantgeek
They work just fine when you have more than a few. And you can even supply them in any order you want.

class Foo {
    public Foo(string a, int b, double c, short d, DateTime e, string f) { }
}

In fairness, I wouldn't really call those "named" parameters. I think some of the perceived unwieldiness comes from when you have maybe 6 properly named parameters...