Added LDM notes for September 13th, 2021.
This commit is contained in:
parent
73dc536d4d
commit
c117a50a14
87
meetings/2021/LDM-2021-09-13.md
Normal file
87
meetings/2021/LDM-2021-09-13.md
Normal file
|
@ -0,0 +1,87 @@
|
||||||
|
# C# Language Design Meeting for September 13th, 2021
|
||||||
|
|
||||||
|
## Agenda
|
||||||
|
|
||||||
|
1. [Feedback on static abstracts in interfaces](#feedback-on-static-abstracts-in-interfaces)
|
||||||
|
|
||||||
|
## Quote(s) of the Day
|
||||||
|
|
||||||
|
- "Computer math never equals real math, it never does"
|
||||||
|
- "If we add default interface methods to LINQ, we get dim sum."
|
||||||
|
|
||||||
|
## Discussion
|
||||||
|
|
||||||
|
https://github.com/dotnet/csharplang/issues/4436
|
||||||
|
|
||||||
|
Today, we looked at some of the initial feedback we've gotten on both static abstracts in interfaces and generic math from our blog posts and on our design issues.
|
||||||
|
Some of the channels we looked at:
|
||||||
|
|
||||||
|
* https://github.com/dotnet/csharplang/issues/4436
|
||||||
|
* https://github.com/dotnet/designs/pull/205
|
||||||
|
* https://devblogs.microsoft.com/dotnet/preview-features-in-net-6-generic-math/
|
||||||
|
* https://www.reddit.com/r/csharp/comments/p20xap/preview_features_in_net_6_generic_math/
|
||||||
|
* https://www.reddit.com/r/dotnet/comments/p20jlc/preview_features_in_net_6_generic_math/
|
||||||
|
* https://www.reddit.com/r/programming/comments/p20j22/preview_features_in_net_6_generic_math/
|
||||||
|
* https://twitter.com/tannergooding/status/1425223277941719040?s=20
|
||||||
|
* https://twitter.com/dotnet/status/1428127070530514944?s=20
|
||||||
|
|
||||||
|
We've also had discussion on our various other platforms not so easily directly linked, such as the C# community discord (https://discord.gg/csharp), email, and
|
||||||
|
other similar informal chats. Overall, we're pleased to see both the number of people looking at the feature, and that their reactions to the feature are overwhelmingly
|
||||||
|
positive. We also received a good deal of concrete feedback we can examine to see what, if anything, we should change or improve about the feature before shipping for
|
||||||
|
real with .NET 7.
|
||||||
|
|
||||||
|
### Keyword confusion
|
||||||
|
|
||||||
|
Some users didn't immediately connect the idea of `static` and `abstract`, and suggested that we might want to consider a new keyword specifically for this concept.
|
||||||
|
However, we think this is another case of initial reactions wanting new features to stand out. This is particularly exacerbated because `abstract` is not used in
|
||||||
|
interfaces today, but is required here. Despite that, we intend to keep the keywords the way we have them: even if we introduced something special for interfaces,
|
||||||
|
we'd want to use `static abstract` in classes when we support defining such methods there.
|
||||||
|
|
||||||
|
### Traits/Shapes/Roles
|
||||||
|
|
||||||
|
Some of the feedback has been about asking us to go further, into traits/shapes/roles/type expansion du jour. This is only natural: static abstracts represents a major
|
||||||
|
new expressive ability in C#, and these types of expansions are the logical next step. While the feature we're currently working is not going to address those requests,
|
||||||
|
we by no means are done in this space, and will continue to explore more enhancements we can make in this space.
|
||||||
|
|
||||||
|
### Missing types
|
||||||
|
|
||||||
|
We didn't get to implementing the generic math interfaces on all types that would benefit from them in .NET 6, such as `BigInteger` or `Vector2/3/4`. We plan to expand
|
||||||
|
our implementations on these interfaces with .NET 7 to cover more types.
|
||||||
|
|
||||||
|
### Direct parsing support in INumber
|
||||||
|
|
||||||
|
Some users have expressed a sentiment that proper mathematical numbers don't necessarily have serialization/deserialization as a concept, and thus asked for INumber to
|
||||||
|
not include those concepts in the extended interface set. This will be a question for the runtime API reviewers to think on.
|
||||||
|
|
||||||
|
### Self types
|
||||||
|
|
||||||
|
Of the biggest pieces of feedback we've gotten is around confusing on type constraints. In particular, users expect calls like `IParsable<double>.Parse("123", null)` to
|
||||||
|
work, but because of the way we've implemented the type constraints currently, the language cannot understand that `double` is the type that `Parse` needs to be constrained
|
||||||
|
to. We can solve issues like this by implementing a self type, which will also just be a generally-useful feature for the language. We're positive about the feature, but
|
||||||
|
it is going to need a decent amount of design work. In particular, there are interfaces such as `IEquatable<T>` that have been in C# since C# 2.0, and we need to think about
|
||||||
|
if we want to be able to apply such a constraint to those interfaces, how that would work, and what level of breaking change it would be. There is also syntax to be worked
|
||||||
|
out, which makes for everyone's favorite LDMs.
|
||||||
|
|
||||||
|
### DIMs for static abstracts
|
||||||
|
|
||||||
|
We consider the ability to have a DIM for static virtual members a must-have for v1, as we'll need it for versioning, and potentially some of the initial implementation will
|
||||||
|
want to be a DIM instead of being required to be implemented by users.
|
||||||
|
|
||||||
|
### `static abstract`s in classes
|
||||||
|
|
||||||
|
The ability to declare `static abstract` members in classes will almost certainly be in the runtime for .NET 7. However, we don't consider it as important of a ship-blocker
|
||||||
|
as the DIM feature, so it might have less priority than other C# 11 features.
|
||||||
|
|
||||||
|
### Checked operators
|
||||||
|
|
||||||
|
https://github.com/dotnet/csharplang/issues/4665
|
||||||
|
|
||||||
|
We think this operator is likely important for semantic correctness in generic math. It's a niche case, and we may want to use the afformentioned DIMs to forward the checked
|
||||||
|
implementation to unchecked, but that will be a decision for the runtime API design team.
|
||||||
|
|
||||||
|
### Relaxing shift operator requirements.
|
||||||
|
|
||||||
|
https://github.com/dotnet/csharplang/issues/4666
|
||||||
|
|
||||||
|
Our thoughts on this proposal have not changed since the [last time](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-05-19.md#relaxing-shift-operator-requirements)
|
||||||
|
we looked at it.
|
|
@ -34,14 +34,16 @@ All schedule items must have a public issue or checked in proposal that can be l
|
||||||
- Feature specs and the C# Standard (Mads, Bill, Rex): https://github.com/dotnet/csharpstandard
|
- Feature specs and the C# Standard (Mads, Bill, Rex): https://github.com/dotnet/csharpstandard
|
||||||
- Permit variable declarations under disjunctive patterns (Julien): draft proposal https://github.com/dotnet/csharplang/pull/4592
|
- Permit variable declarations under disjunctive patterns (Julien): draft proposal https://github.com/dotnet/csharplang/pull/4592
|
||||||
|
|
||||||
## Sep 13, 2021
|
|
||||||
|
|
||||||
- Generic math and static abstracts feedback (Tanner): https://devblogs.microsoft.com/dotnet/preview-features-in-net-6-generic-math/
|
|
||||||
|
|
||||||
# C# Language Design Notes for 2021
|
# C# Language Design Notes for 2021
|
||||||
|
|
||||||
Overview of meetings and agendas for 2021
|
Overview of meetings and agendas for 2021
|
||||||
|
|
||||||
|
## Sep 13, 2021
|
||||||
|
|
||||||
|
[C# Language Design Notes for September 13th, 2021](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-13.md)
|
||||||
|
|
||||||
|
1. Feedback on static abstracts in interfaces
|
||||||
|
|
||||||
## Sep 1, 2021
|
## Sep 1, 2021
|
||||||
|
|
||||||
[C# Language Design Notes for September 1st, 2021](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-01.md)
|
[C# Language Design Notes for September 1st, 2021](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-01.md)
|
||||||
|
|
Loading…
Reference in a new issue