213 lines
8.6 KiB
Markdown
213 lines
8.6 KiB
Markdown
# C# Language Design Meeting for July 13th, 2020
|
|
|
|
## Agenda
|
|
|
|
1. [Generics and generic type parameters in aliases](#Generics-and-generic-type-parameters-in-aliases)
|
|
2. ["closed" enum types](#"closed"-enum-types)
|
|
3. [Allow `ref` assignment for switch expressions](#Allow-`ref`-assignment-for-switch-expressions)
|
|
4. [Null suppressions nested under propagation operators](#Null-suppressions-nested-under-propagation-operators)
|
|
5. [Relax rules for trailing whitespaces in format specifier](#Relax-rules-for-trailing-whitespaces-in-format-specifier)
|
|
6. [Private field consideration in structs during definite assignment analysis](#Private-field-consideration-in-structs-during-definite-assignment-analysis)
|
|
7. [List patterns](#list-patterns)
|
|
8. [Property-scoped fields and the `field` keyword](#Property-scoped-fields-and-the-field-keyword)
|
|
9. [File-scoped namespaces](#file-scoped-namespaces)
|
|
10. [Allowing `ref`/`out` on lambda parameters without explicit type](#Allowing-ref/out-on-lambda-parameters-without-explicit-type)
|
|
11. [Using declarations with a discard](#Using-declarations-with-a-discard)
|
|
12. [Allow null-conditional operator on the left hand side of an assignment](#Allow-null-conditional-operator-on-the-left-hand-side-of-an-assignment)
|
|
12. [Top level statements and functions](#Top-level-statements-and-functions)
|
|
13. [Implicit usings](#implicit-usings)
|
|
|
|
## Quote of the day
|
|
|
|
"It does actually seem like this pattern is the 98% case..."
|
|
"I just want to disagree with something [redacted] said... [they] said [they] thought it was the 98% case that this would apply to, and I think it's 99..."
|
|
"Not fair, I was going to say that."
|
|
|
|
## Discussion
|
|
|
|
This meeting was issue triage. There will not be much detail on any particular issue, just a general summary
|
|
of the LDM's feeling and the milestone that we triaged to.
|
|
|
|
### Generics and generic type parameters in aliases
|
|
|
|
https://github.com/dotnet/csharplang/issues/1239
|
|
|
|
In general, we want to make improvements in this area. We should also be open to making other enhancements
|
|
in this space, such as allowing tuple syntax on the right side, or allowing C# keywords like `int`. There's
|
|
also a set of features that we should investigate in parallel, such as globally-visible aliases or publicly-
|
|
exported aliases.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged for C# 10 for now so that we can look at the space hollistically in the near term.
|
|
|
|
### "closed" enum types
|
|
|
|
https://github.com/dotnet/csharplang/issues/3179
|
|
|
|
This is a solution to the very common complaints around enum usage, particularly in switch expressions and other
|
|
exhaustiveness scenarios. It will also work well with DUs, and we should make sure that whatever syntax we use
|
|
there works well with closed or sealed enum types as well.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged for C# 10 to look at in coordination with DUs.
|
|
|
|
### Allow `ref` assignment for switch expressions
|
|
|
|
https://github.com/dotnet/csharplang/issues/3326
|
|
|
|
We like this proposal. You can already do this with ternaries, and it's odd that you can't do this with switch
|
|
expressions as well. It's not high priority, but we'd be happy to see it in the language. Like ternaries, the
|
|
ref version would not be target-typed.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged for Any Time.
|
|
|
|
### Null suppressions nested under propagation operators
|
|
|
|
https://github.com/dotnet/csharplang/issues/3393
|
|
|
|
This will be a breaking change, so we need to get it in as soon as possible.
|
|
|
|
#### Conclusion
|
|
|
|
C# 9 timeframe. We need to make a syntax proposal and approve it.
|
|
|
|
### Relax rules for trailing whitespaces in format specifier
|
|
|
|
https://github.com/dotnet/csharplang/issues/3414
|
|
|
|
In reading this proposal, we're unsure whether the request was for _ignoring_ trailing spaces in format specifiers,
|
|
or allowing them and including them in the format specifier. We think that either way this is interpreted, it will
|
|
be confusing: trailing spaces are allowed in front of an interpolated expression and mean nothing, but for things
|
|
like `DateTime`, spaces are valid parts of a format specifier and will be respected in the output. We think that
|
|
either behavior here would be confusing, with no clear indication on which the user wants.
|
|
|
|
#### Conclusion
|
|
|
|
Rejected.
|
|
|
|
### Private field consideration in structs during definite assignment analysis
|
|
|
|
https://github.com/dotnet/csharplang/issues/3431
|
|
|
|
This is a bug from the native compiler that had to be reimplemented in Roslyn for compat, but it's always been
|
|
one of the prime candidates for a warning wave (and is already supported as an error in the compiler via the strict
|
|
feature flag). There is some contention whether it should be a warning or an error in this wave. There is also a
|
|
concern that this will combine with the `SkipLocalsInit` feature in C# 9 to expose an uninitialized memory hole in
|
|
C# with no use of `unsafe` or `System.Unsafe` required.
|
|
|
|
#### Conclusion
|
|
|
|
We need to look at this ASAP to make sure that we don't unintentionally expose unsafety in the language without
|
|
user intention. We'll schedule this for next week.
|
|
|
|
### Remove restriction that optional parameters must be trailing
|
|
|
|
https://github.com/dotnet/csharplang/issues/3434
|
|
|
|
It's possible to define such methods in metadata with the correct attribute usage _and_ call them from C# today.
|
|
This would just be about removing the restriction from _defining_ them in C#.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged for Any Time.
|
|
|
|
### List patterns
|
|
|
|
https://github.com/dotnet/csharplang/issues/3435
|
|
|
|
We have an open proposal that with a prototype. We like the general direction it takes, but we need to have more
|
|
detailed design review of it and possibly make a few different decisions. This is a direction we want to take
|
|
pattern matching in future releases, so we'll continue iterating on this.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged into C# 10 for design work.
|
|
|
|
### Property-scoped fields and the `field` keyword
|
|
|
|
* https://github.com/dotnet/csharplang/issues/133
|
|
* https://github.com/dotnet/csharplang/issues/140
|
|
|
|
We've started doing design work around both of these issues. We should continue doing that.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged into C# 10.
|
|
|
|
### File-scoped namespaces
|
|
|
|
https://github.com/dotnet/csharplang/issues/137
|
|
|
|
This has been a large request for a long time that reflects the default of almost every single C# file written.
|
|
There's still some design work to do, particularly in how that will affect `using` statements, but it's work
|
|
that we should take on.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged into C# 10.
|
|
|
|
### Allowing `ref`/`out` on lambda parameters without explicit type
|
|
|
|
https://github.com/dotnet/csharplang/issues/338
|
|
|
|
We've heard this request a few times, and while we don't see any particular issue with this, it's not a priority
|
|
for the team at this point. If a spec/implementation was provided we'd likely accept it but won't go out of our
|
|
way to add it unless something else changes here.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged to Any Time.
|
|
|
|
### Using declarations with a discard
|
|
|
|
https://github.com/dotnet/csharplang/issues/2235
|
|
|
|
There's still some open design questions here, particularly around possibly ambiguous syntaxes. We need to keep
|
|
iterating on this to find a design that we like.
|
|
|
|
#### Conclusion
|
|
|
|
Triaged for X.X, pending a new proposal.
|
|
|
|
### Allow null-conditional operator on the left hand side of an assignment
|
|
|
|
https://github.com/dotnet/csharplang/issues/2883
|
|
|
|
Initial discussion shows a big LDT split on whether `?.` should be able to effectively a conditional ref. We
|
|
would need to discuss further, but aren't ready to outright approve or reject the feature.
|
|
|
|
#### Conclusion
|
|
|
|
Triage to X.X for future discussion.
|
|
|
|
### Top level statements and functions
|
|
|
|
https://github.com/dotnet/csharplang/issues/3117
|
|
|
|
This is part 2 of the work we started in C# 9 with top-level statements: designing free-floating functions that
|
|
can sit on the top level without any containing type. We need to continue examining this context of scripting
|
|
unification, which we plan to continue doing on an ongoing basis.
|
|
|
|
#### Conclusion
|
|
|
|
Triage into C# 10 for ongoing discussion.
|
|
|
|
### Implicit usings
|
|
|
|
https://github.com/dotnet/csharplang/issues/3428
|
|
|
|
This is another issue arising of discussions on top-level statements and using C# as a scripting language:
|
|
attempting to make the language more brief by specifying common imports on the command line or as part of
|
|
the project file is certainly one way to remove boilerplate. However, it's a controversial feature that often
|
|
draws visceral reactions. We need to discuss this more and figure out if it's a feature we want to have in C#,
|
|
taking into account our increased focus on scripting-like scenarios. It's worth noting that CSX has a limited
|
|
form of this support already, and implementing this in C# proper would bring us one step closer to unifying the
|
|
two dialects.
|
|
|
|
#### Conclusion
|
|
|
|
Triage to C# 10 for discussion.
|