csharplang/meetings/2020/LDM-2020-10-14.md

C# Language Design Meeting for October 14th, 2020

Agenda

1. Triage
   1. Repeated Attributes in Partial Members
   2. Permit a fixed field to be declared inside a readonly struct
   3. Do not require fixing a fixed field of a ref struct
   4. params Span
   5. Sequence Expressions
   6. utf8 string literals
   7. pattern-based with expressions
   8. Property improvements
   9. File scoped namespaces
   10. Discriminated Unions
   11. Efficient params and string formatting
   12. Allow omitting unused parameters
2. Milestone Simplification

Quote of the Day

• "I used to have a fidget cube, but then [redacted] took away my fidget cube because it was apparently a very annoying device for everyone else"

Discussion

Triage

Repeated Attributes in Partial Members

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

We discussed this briefly at the tail-end of C# 9 work, and came to the conclusion this is an issue for source generator authors and that we wanted to make it work. Triaged into the working set.

Permit a fixed field to be declared inside a readonly struct

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

This is part of the feature we discussed Monday. Triage into the working set.

Do not require fixing a fixed field of a ref struct

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

We generally like the idea of this feature: language-wise it's small, makes sense, and is an annoyance for users of ref structs. However, the implementation of fixed in Roslyn has historically been an issue with a long bug trail coming every time we need to make a change. We think this makes sense the next time we need to a larger feature around fixed that would force us to refactor the handling of fixed in the compiler. Until then, we don't think the implementation cost is worth it. Triaged to the backlog.

params Span

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

We like this feature. We'll need to carefully design the overload resolution rules such that it wins out over existing params arrays. Libraries can then intentionally opt-in by introducing Span<T> overloads, just like they can introduce any new overload today that causes a change in behavior when recompiled. Triaged into the working set.

Sequence Expressions

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

Related to #3038, #3037, and #3086, which are all in the working set. We'll be taking a look at the whole scenario in the upcoming design period, so this is triaged into the working set with the others.

utf8 string literals

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

We need the runtime to make progress here. While we could consider ways to make it easier to declare constant utf-8 byte arrays, we feel that would likely box us in when the runtime wants to move forward in this area. When they're ready, we can put this back on the agenda. Triaged into the backlog.

pattern-based with expressions

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

This is part of the next round of record work, so into the working set it goes. We may need to think about how general object might be able to do object reuse as part of a with (Roslyn would not be able use it to replace BoundNode.Update as spec'd for records, for example), so that is a scenario we need to keep in mind as we generalize.

Property improvements

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

We've discussed these recently in LDM. We're moving forward with design, starting with #133. Triaged into the working set.

File scoped namespaces

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

Triaged into the working set. We'll need to come up with a more complete proposal than we have currently, particularly considering how it will interact with top-level statements, but it doesn't seem too difficult.

Discriminated Unions

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

This is one of the next big C# tent poles we're looking to address, and we're working on an updated proposal after having some time to ruminate on the previous proposals in the area and post initial records. We have lots of design work to do, so into the working set it goes.

Efficient params and string formatting

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

Interpolated strings are a pit of failure in certain scenarios, such as logging, where formatting costs are incurred up front even if they're not needed. We'll keep this in the working set to keep iterating on proposals. We know we want to do some work here, but we're not sure exactly how it will function yet.

Allow omitting unused parameters

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

We had some initial questions around the metadata representation of discards: should the be nameless, for example? We generally like proposals that put discards in more places, and we're willing to look at a complete proposal if one is presented. Triaged to any time.

Milestone Simplification

Today, we have quite a few milestones that mean various things at various points in time, and it's hard for outsiders to keep track of what is on track for what. This is further complicated by the fact that sometimes things are just not known: we could be working on a feature with every intention to put it in the next version of C#, but fully acknowledging it might not make it. Or we may be doing design work for a feature that we know definitely will not make it into the next version of C#, but needs to have work done or we'll never get it at all. For this reason, we're simplifying our milestones to be more clear about what the state of things is:

• Working Set is the set of proposals that the LDT is currently actively working on. Not everything in this milestone will make the next version of C#, but it will get design time during the upcoming release.
• Backlog is the set of proposals that members of the LDT have championed, but are not actively working on. While discussion and ideas from the community are welcomed on these proposals, the cost of the design work and implementation review on these features is too high for us to consider community implementation until we are ready for it.
• Any Time is the set of proposals that members of the LDT have championed, but are not being actively worked on and are open to community implementation. We'll go through these shortly and label the ones that need to have a specification added vs the ones that have an approved spec and just need implementation work. Those that need a specification still need to be presented during LDM for approval of the spec, but we are willing to take the time to do so at our earliest convenience.
• Likely Never is the set of proposals that the LDM has reject from the language. Without strong need or community feedback, these proposals will not be considered in the future.
• Numbered milestones are the set of features that have been implemented for that particular language version. For closed milestones, these are the set of things that shipped with that release. For open milestones, features can be potentially pulled later if we discover compatability or other issues as we near release.