3.9 KiB
C# Language Design Meeting for September 14th, 2020
Agenda
Quote of the day
- "It's my version of thanks Obama, thanks C#"
Discussion
Required Properties
https://github.com/dotnet/csharplang/issues/3630
Most of the time today was used hearing a presentation about a proposal for required properties. This presentation was intended as a high-level overview of the issue required properties are attempting to solve, and to illustrate a few approaches that could be taken for implementing these. Notes were not taken to the slide content itself, as the slides are linked above.
Overall, the LDM is a bit leary about the implementation complexity of runtime-verification methods. One approach that wasn't on the slides, but is a possible approach, is introducing validators and letting type authors do the verification themselves. This may end up resulting in type authors conflating nullability and requiredness for most simple implementations, but for the common scenarios this may be just fine. We were unable to find just one implementation strategy that stuck out as "this is the right thing to do." Instead, each implementation strategy had a set of tradeoffs, particularly around the implementation complexity of tracking whether a property has been initialized.
One thing that we noted from the presentation is that any method of introducing required properties is going to mean that types with
these contracts on their empty constructors will not be able to be used in generic scenarios where T : new(), as the empty constructor
is required to set some amount of properties. The presentation also did not cover how to do additive or subtractive contracts: ie, a
future factory method MakeAMads might want to specify "Everything from the normal Person constructor except FirstName", whereas
a copy constructor would want to specify "You don't have to initialize anything". Some work has started on designing this scenario,
but it needs some more work before it's in a state to get meaningful feedback.
A read of the room found that most of the LDM was leaning towards compile-time only validation of required properties. It does mean that upgrading binary versions without recompiling can leave things in an invalid state, but the implementation strategies for getting actual runtime breaks are very complex and we're not sure they're worth the tradeoff. The next step in design will be to come back with a more concrete syntax proposal for how required properties will be stated, and how constructors will declare their contracts.
Triage
We only had time left to triage 1 issue:
Proposal: Permit trailing commas in method signatures and invocations
https://github.com/dotnet/csharplang/issues/391
This is a longstanding friction point in the language that has mostly positive sentiment on csharplang. We're also fairly confident that it wouldn't break any possible language features other than omitted arguments, which the LDM is not particularly interested in pursuing. That being said, the general gut reaction of most LDM members is something along the lines of "This looks wrong." We certainly acknowledge that, despite some syntactic misgivings, this can be a very useful feature, particularly for source generators and refactorings, as well as for just simply reordering parameters in a method call or definition. There are a couple of open issues we'd need to resolve as well:
- What would happen with param arrays?
- Would tuple declarations be allowed to have trailing commas? This proposal actually seems like a natural way to allow oneples into the language, in a similar style to Python, where the oneple must have a trailing comma.
Conclusion
Triage in X.0. We think this feature has a place in C#, but we don't think it will make the bar for what we're interested in with C# 10.