Notes for August 31st, 2022

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-08-31.md

1. Short term work triage
   1. Partial properties
   2. Using aliases for any type
   3. Null-conditional assignment
   4. await?
   5. params IEnumerable
   6. Discriminated Unions
   7. Roles
   8. pragma warning enable
   9. Ignored directives support
   10. Primary constructors
   11. Switch expression as a statement

[TahirAhmadov]

I'm excited for await?.
Also, for params IEnumerable<T>, can we at least come to a clear understanding of what needs to be supported in a perfect world? Meaning, if we forget the existence of params T[] for a moment, and could add params Span<T> support to the runtime, what would be the ideal solution? I'm a little unclear on this because IEnumerable<T> and Span<T> are not compatible; the way I see it, it will be necessary to define both overloads. Basically - million bucks question - can we create one params to rule them all? One which would take IEnumerable<T> and Span<T> impicitly?

[HaloFour]

Primary constructors are already in the language, it makes sense to explore how they might be supported with non-records. The "debate" that arose during the CodePlex days was largely around trying to make them have parity with normal constructors by allowing raw code statements to appear within the body of the method. IMO none of that is necessary to still bring benefits to the language.

[333fred]

@MgSam it is specifically on the prototyping shortlist because we feel that doing so will help drive the design.

[MgSam]

IMO none of that is necessary to still bring benefits to the language.

I'm sure others will disagree. 🙂

[HaloFour]

@MgSam

I'm sure others will disagree. 🙂

Sure, I doubt any design decisions have ever been unanimous. That is my opinion, though, based on my experience with working with other languages that have these constructs where they are usually opinionated to a degree. They don't have to achieve parity because you always have the escape hatch of defining a full constructor. The question is how many use cases you can cover before you hit a cliff edge, and how steep that is.

[HaloFour]

Admittedly I think most of the benefits of primary constructors for non-record types could be achieved via source generators. To borrow a page from Lombok:

[RequiredArgsConstructor]
public partial class Person {
    private readonly string name;
    private readonly int age;
}

// generated:
public partial class Person {
    public Person(string name, int age) {
        this.name = name;
        this.age = age;
    }
}