# C# Language Design Meeting for August 30th, 2021

## Agenda

1. C# 11 Initial Triage
    1. [Generic attributes](#generic-attributes)
    2. [`field` keyword](#field-keyword)
    3. [List patterns](#list-patterns)
    4. [Static abstracts in interfaces](#static-abstracts-in-interfaces)
    5. [Declarations under `or` patterns](#declarations-under-or-patterns)
    6. [Records and initialization](#records-and-initialization)
    7. [Discriminated unions](#discriminated-unions)
    8. [Params `Span<T>`](#params-spant)
    9. [Statements as expressions](#statements-as-expressions)
    10. [Expression trees](#expression-trees)
    11. [Type system extensions](#type-system-extensions)

## Quote(s) of the Day

- "Any proposals for a prioritization strategy?"
- "I'm not going to run a ranked choice algorithm in real time"
- "By small, I mean large"
- "Even Midori wasn't crazy enough to put ref and out into the type system" "Maybe that's what went wrong"
- "If you're using ref fields for something other than performance, come talk to me and we can find you help"

## Discussion

Today, we start our _initial_ triaging passes for C# 11. It's important to note that, while we talked about a number of potential features for
this cycle, it's extremely unlikely we'll be able to get to all of them. These triage sessions are a good way to see what the LDM is currently
thinking about, but please don't try to speculate about what's in or out of C# 11 from them. We don't even know that yet.

### Generic Attributes

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

We're shipping this in preview in C# 10 because we found a number of late-breaking incompatibilities with other tools. C++/CLI will straight-up
crash if it encounters an assembly with a generic attribute, even if the type with the attribute is entirely unused, and they're not the only
tool with issues. We'll need to work with them and others to make sure the ecosystem won't crash around generic attributes before we can remove
the preview flag.

### `field` keyword

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

Didn't quite have time for this in 10. Let's get it done!

### List patterns

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

We have a syntactic design and semantic design for arrays and indexable types, but we will need to some more work for `IEnumerable` support.
We hope to have an initial preview soon into the C# 11 development cycle to help get user feedback on the design choices we've made so far.

### Static abstracts in interfaces

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

We'll need to look through the feedback consumers give us on the initial preview. We already know that CRTP (ie, `INumeric<T> where T : INumeric<T>`)
might be better served with `this` type constraint, and if we do want to have such a constraint we'll want it now so that the generic math
interfaces can use it where appropriate.

### Declarations under `or` patterns

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

This is one of our more common pattern complaints. Let's try and get this done.

### Records and initialization

We have a number of topics around both records and initialization:

1. Required properties
2. Final initializers
3. Factories
4. Primary constructors
5. Public init fields
6. Immutable collection initializers
7. Combined object and collection initializers
8. Nested properties in with-exprs
9. Event hookup in object initializers

We'll look at triaging this list in the next meeting.

### Discriminated unions

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

There is a ton of interest in this, both within the LDM and in the wider community. At the same time, this is a potentially broad topic, broader
than records, and we have not yet done the work to fully explore the space and break things into individual parts that can combine into a bigger
whole like we did with records. We'll need to start that now if we ever want to ship something in this space (and we do).

### Params `Span<T>`

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

This was initially going to be part of the improved interpolated strings proposal, but that feature grew and pushed this part out of scope. We'll
need to work together with the runtime on this to make sure that we're stackalloc'ing where possible but not unnecessarily blowing out stacks. It
might also call for being able to stackalloc an array of reference types.

### Statements as expressions

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

We see potential for smaller features here that we can ship one at a time, leaving design priority for other features.

### Expression trees

https://github.com/dotnet/csharplang/discussions/4727

Historically, our inability to improve this space has been because of concern about breaking our customers. However, recent discussions between
EF and members of the LDT have us encouraged, and we plan to look at this.

### Type system extensions

There are a number of type system improvements we could look at, from large changes like roles and extension everything to smaller things such as
unifying our story around `Task` and `Task<T>`/`Action` and `Func`/etc. This last thing would require some kind of unit-type, and `void` is the
obvious choice as it's already the return type of nothing-returning methods. Maybe we could work with the BCL to unify these types and make them
transparent? We could also look at generic improvements around other restricted types, such as pointers and ref structs.
