C# Language Design Notes for Aug 28, 2019

Agenda

1. 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