Skip to content

Latest commit

 

History

History
120 lines (72 loc) · 5.85 KB

LDM-2023-10-09.md

File metadata and controls

120 lines (72 loc) · 5.85 KB

C# Language Design Meeting for October 9th, 2023

Agenda

Quote of the Day

  • "I think the disagreement was primarily around Javascript, so we'll leave that out"

Discussion

Today was a triage day. We went through championed issues without a milestone to assign them an appropriate milestone for future work. The query we use for this is https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+label%3A%22Proposal+champion%22+no%3Amilestone.

ReadOnlySpan initialization from static data

#5295

Much of the desire for specific syntax here has been addressed by a combination of things in C# 12:

  • Collection expressions provide a syntax that doesn't contain new and necessarily imply that it is actually creating a new collection.
  • Collection expressions for this scenario have a set of promises enshrined in the spec for when they won't allocate, and we have a warning for when that's violated.
  • There are additional scenarios that the compiler does not allocate today, and we have a hidden diagnostic that users that care about this scenario can turn on to ensure that they aren't violating these rules, either now or in the future. This set of rules is implementation-defined, which is why the diagnostic must be opted into by users, but it does cover the scenario.

We could in the future think about potential const expansions to ensure that nothing is violated, such as const [1, 2, 3], but that's a much bigger proposal and potentially gets into the larger weeds of broad constexpr support in C#, and can be revisited later.

Conclusion

Rejected, request subsumbed by C# 12 features.

Embedded Language Indicators for raw string literals

#6247

This is, in terms of compiler work, an extremely small feature. However, the broader concern is tooling support. If we enshrine this in the language itself, we may then need a tooling support bar we currently don't have. Colorization of languages today is driven by comments or StringSyntaxAttribute, and there's a bit of a chicken-and-egg problem here. If the language had more explicit support for the feature, this may drive more investment into tooling; but because we don't have super broad adoption of the existing feature, it can be hard to justify the investment. We think the feature would be a good one to have, but that we're not going to prioritize it at this time.

Conclusion

Backlog

list-patterns on enumerables

#6574

This is follow-up work from C# 11 that we did not have time in C# 12 to invest in. We intend to continue the work here now; collection expressions supporting more than just indexable and countable types show where our list pattern support falls short.

Conclusion

Working set

Make generated `Program`` for top-level statements public by default

#6769

The primary argument for this feature is improving testability, but we think this feature alone wouldn't be enough to fix testing. For example, users wanting to test their entrypoint still can't do so, because it's unnameable. We think a more holistic look at the testing space is required before we move forward with this one.

Conclusion

Needs more work

CallerCharacterNumberAttribute

#3992

This is an interceptors-adjacent feature. As we continue to develop interceptors or possible replacements for C# 13, we will want to consider this alongside it. It shouldn't be considered alone.

Conclusion

Grouped with #7009.

Add private and namespace accessibility modifiers for top-level types

#6794

This is in many ways a follow-on to the improvements we made with file, but this time targeted more at standard users, and less at source-generator authors. We think that there's room to improve the story around encapsulating functionality, particularly for larger codebases, and want to flesh this proposal out and see where it leads us.

Conclusion

Working set

Require await to apply nullable postconditions to task-returning calls

#6888

This still needs to be updated to address feedback from the last time that it was brought up.

Conclusion

Needs more work

is expression evaluating const expression should be considered constant

#6926

This is a consistency issue: you can use == in a constant expression, but not is. We think this can be addressed, but needs a complete specification. It should probably also look at switch expressions at the same time.

Conclusion

Any time, needs an approved specification.