maxmustermann/csharplang
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Added notes for October 14th, 2020

Browse source
This commit is contained in:
Fredric Silberberg 2020-10-14 14:57:29 -07:00
parent 87adc18115
commit 843230d5c0
No known key found for this signature in database
GPG key ID: BB6144C8A0CEC8EE
2 changed files with 145 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

138
meetings/2020/LDM-2020-10-14.md Normal file
View file

@ -0,0 +1,138 @@
# C# Language Design Meeting for October 14th, 2020
## Agenda
1. [Triage](#triage)
1. [Repeated Attributes in Partial Members](#repeated-attributes-in-partial-members)
2. [Permit a fixed field to be declared inside a readonly struct](#permit-a-fixed-field-to-be-declared-inside-a-readonly-struct)
3. [Do not require fixing a fixed field of a ref struct](#do-not-require-fixing-a-fixed-field-of-a-ref-struct)
4. [params Span<T>](#params-spant)
5. [Sequence Expressions](#sequence-expressions)
6. [utf8 string literals](#utf8-string-literals)
7. [pattern-based `with` expressions](#pattern-based-with-expressions)
8. [Property improvements](#property-improvements)
9. [File scoped namespaces](#file-scoped-namespaces)
10. [Discriminated Unions](#discriminated-unions)
11. [Efficient params and string formatting](#efficient-params-and-string-formatting)
12. [Allow omitting unused parameters](#allow-omitting-unused-parameters)
2. [Milestone Simplification](#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<T>
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.

11
meetings/2020/README.md
View file

@ -23,14 +23,17 @@
## Oct 19, 2020
## Oct 14, 2020
- Triage for [C# 10 working set](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+milestone%3A%2210.0+Working+Set%22) (Mads)
# C# Language Design Notes for 2020
Overview of meetings and agendas for 2020
## Oct 14, 2020
[C# Language Design Notes for October 14th, 2020](https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-10-14.md)
- Triage
- Milestone Simplification
## Oct 12, 2020
[C# Language Design Notes for October 12th, 2020](https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-10-12.md)