5 KiB
C# Language Design Notes for Aug 28, 2019
Agenda
- Triage
Discussion
Hiding with optional parameters
If you define a method with optional parameters with the same name as a method
in a base class, we do not provide a warning that the method is hiding the method
in the base class, and if you put the new
keyword, that provides a warning. Do
we want to provide a warning in a warning wave that the method is hiding and some
mechanism of silencing the warning (presumably allowing new
).
Conclusion
If warning waves are here, we're comfortable taking this.
params Span<T>
and string formatting
There are a lot of important performance implications here. We think it should be done soon, for the latest major release.
Conclusion
Agreed, next major release. (C# 9.0)
Allow sizeof
in safe code
There have been requests for this over the years, but we're not sure of the actual value of the feature.
Conclusion
Rejected, until we hear compelling use cases.
Tail return
recursive calls
We could do "immediate" recursion (directly calling the containing method) without
depending on the runtime because we could implement it using compiler rewrites, but
it does seem like we would want to support mutual recursion or even just tail-dispatch.
This would require us to either accept the limitations in the CLR where a tail
is
not always done in constant space, or require a CLR feature that guarantees constant space
However, we've done without tail calls for a quite a long time and there are some workarounds.
Conclusion
Let's talk about this later, for a C# 10.0.
Variant method overrides
We previously pushed out overrides with variance (covariant returns, contravariant parameters) due to requiring quadratic stubs to be emitted for the runtime. Now we can explore runtime changes to support variance directly, where the runtime would allow overrides to differ with "compatible" signatures, instead of exact matches, which is what is required right now.
Conclusion
There's a lot of existing use cases for this feature, and there's some feeling that it may be required for the records feature. Discussion with the runtime says that it would not be very expensive, and is tractable for the next major release. We're scheduling this for C# 9.0.
Exponentiation operator (**
)
This seems to be the major missing mathematical operator in C#. We like it as part of a broader improvement to mathematical generalization that we're planning in the "shapes" proposals.
Conclusion
C# 10.0, matched up with shapes.
base(T)
with runtime changes
This is a follow-up feature for C# 8.0, so we'd like to do it as quickly possible.
Conclusion
Next major release, C# 9.0.
Switching on ReadOnlySpan<char>
with constant strings
We aren't ready to commit resources to it, since we haven't found blocking issues, but we'd take the improvement whenever it's ready.
Conclusion
Any time.
Permit a fixed field to be declared inside a readonly struct
We'd like to address performance issues soon if they're impactful enough.
Conclusion
Keep it in C# 9.0, pending confirmation of performance impact.
Safe fixed-size buffers
This one has some compelling perf scenarios, but we don't have a clear design nailed down.
Conclusion
We'd like to take in a major release, but we need a solid design first.
Comparison, and
/or
/not
patterns
These seem useful and they are most useful with the and
/or
patterns.
Conclusion
This doesn't seem very big and we think it could fit in any release. C# 9.0 for now. Same
for and
/or
patterns.
Dictionary Literals
Initialization of collection data structures, including immutable data structures, is a known issue, in both performance and ergonomics. This proposal doesn't really address these problems and special cases Dictionary<K,V>, even though we know the problem also exists for other types.
Conclusion
The proposal in its current form is rejected. We'd rather try to address more problems in a single feature, potentially after the records feature, which has proposals around initialization of immutable types.
No-arg constructor/non-defaultable value types
We're not very excited about it, but there are valid use cases. We previously pulled the feature because there was a runtime bug that did not call the constructor in certain cases. That bug has now been fixed.
Conclusion
Target-typed conditional expression
We know it's useful and we have a design that we think would work.
Conclusion
We would like to do this for C# 9.0
Surrogate pairs in Unicode-escaped code points in identifiers
The language spec already says this is allowed.
Conclusion
If we have a viable implementation, we'll take it whenever.
Permit conditional operation with int?
and double operands
This is separate from target-typing because it would change the common type algorithm, but it also interacts with the target-typing, so we probably need to do them together.
Conclusion
Discuss before C# 9.0