csharplang/meetings/2021/LDM-2021-08-30.md
2021-09-02 13:54:25 -07:00

112 lines
5.2 KiB
Markdown

# C# Language Design Meeting for August 30th, 2021
## Agenda
1. C# 11 Initial Triage
1. [Generic attributes](#generic-attributes)
2. [List patterns](#list-patterns)
3. [Static abstracts in interfaces](#static-abstracts-in-interfaces)
4. [Declarations under `or` patterns](#declarations-under-or-patterns)
5. [Records and initialization](#records-and-initialization)
6. [Discriminated unions](#discriminated-unions)
7. [Params `Span<T>`](#params-spant)
8. [Statements as expressions](#statements-as-expressions)
9. [Expression trees](#expression-trees)
10. [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 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.
### 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.