# C# Language Design Meeting for October 9th, 2023

## Agenda

- [Triage](#discussion)
    - [ReadOnlySpan initialization from static data](#readonlyspan-initialization-from-static-data)
    - [Embedded Language Indicators for raw string literals](#embedded-language-indicators-for-raw-string-literals)
    - [list-patterns on enumerables](#list-patterns-on-enumerables)
    - [Make generated \`Program\`\` for top-level statements public by default](#make-generated-program-for-top-level-statements-public-by-default)
    - [CallerCharacterNumberAttribute](#callercharacternumberattribute)
    - [Add private and namespace accessibility modifiers for top-level types](#add-private-and-namespace-accessibility-modifiers-for-top-level-types)
    - [Require await to apply nullable postconditions to task-returning calls](#require-await-to-apply-nullable-postconditions-to-task-returning-calls)
    - [`is` expression evaluating `const` expression should be considered constant](#is-expression-evaluating-const-expression-should-be-considered-constant)

## 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

https://github.com/dotnet/csharplang/issues/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

https://github.com/dotnet/csharplang/issues/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

https://github.com/dotnet/csharplang/issues/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

https://github.com/dotnet/csharplang/issues/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

https://github.com/dotnet/csharplang/issues/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 https://github.com/dotnet/csharplang/issues/7009.

### Add private and namespace accessibility modifiers for top-level types

https://github.com/dotnet/csharplang/issues/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

https://github.com/dotnet/csharplang/issues/6888

This still needs to be updated to address feedback from the last time that it was
[brought up](https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-01-18.md#nullable-post-conditions-and-asyncawait).

#### Conclusion

Needs more work

### `is` expression evaluating `const` expression should be considered constant

https://github.com/dotnet/csharplang/issues/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.
