# C# Language Design Meeting for September 14th, 2020

## Agenda

1. [Required Properties](#required-properties)
2. [Triage](#triage)

## Quote of the day

- "It's my version of thanks Obama, thanks C#"

## Discussion

### Required Properties

https://github.com/dotnet/csharplang/issues/3630

[Presentation](./Required_Properties_2020_09_16.pdf)

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.
