C# Language Design Meeting for March 13th, 2023

Agenda

• Unsafe in aliases hole
• Attributes on primary ctors

Quote(s) of the Day

• "The quote of the day will be 'We have 2 small topics', and the agenda will only have 1 topic."
• "We only have 5 minutes left, let's see if we can do it really quickly." everyone starts talking really fast

Discussion

Unsafe in aliases hole

https://github.com/dotnet/roslyn/issues/67281

We started today by looking at an existing hole in the enforcement of unsafe for pointer types, nested as the element type of an array in a type parameter to a generic type (such as List<int*[]>). This hole has existed for as long as generics have, but now presents us with an inconsistency in the C# 12 using enhancements feature, as it introduces using unsafe. In brainstorming, we came up with the following options:

1. Keep the status quo. This will mean that most usages of unsafe types in using will require unsafe, except those types contained inside type parameters.
2. Produce an error across all language versions, and require unsafe. This will break older consumers that have aliases like this defined.
3. Produce an error conditionally on language version 12. This has 2 suboptions:
   1. Give warnings on lower language levels.
   2. Do not give warnings on lower language levels.
4. Make this a warning wave in C# 12. This will also result in inconsistent experience like #1, but there will be a diagnostic in all scenarios.
5. Don't add unsafe to usings in general, and do not require them for unsafe types in usings.

We framed these options of what they do for the future and past of the language:

• 1 would result in an inconsistent future for the language, and we have no reason to believe that code like this exists nearly anywhere at all. No search results for it appear in any of our usual sources, when other breaking changes we've made do sometimes appear in searches of GitHub or internal MS code.
• 2 would be consistent for the future, but leave the past with no escape hatch.
• 3 would be consistent for the future, and leave the past as it is; but the new warnings from a could potentially be an issue for users who are just upgrading their toolsets.
• 4, while not as inconsistent as 1, would still leave the future inconsistent, which we do not like.
• 5 would be consistent with the past and the future, but the reasons we chose to have using unsafe in the first place are still relevant. We don't want to adjust the future of the language based on a bug.

Based on this discussion, we think 3b is the best option that maximizes forward direction while letting past code continue existing.

Conclusion

We chose option 3b, producing an error on this code in C# 12 and up, and not giving warnings in lower language versions.

Attributes on primary ctors

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

In our speedrun session for this issue, we briefly considered whether method in this location is obviously on the primary ctor: could it conceivably be confused with the copy ctor or deconstructor. However, we already have documentation comments on the parameters, and those don't get applied in either of the aforementioned locations. Attributes on the parameters are also only applied to the primary ctor, not to the deconstructor. Given those, we're ok with this proposal.

We then determined what bucket to put it in. For now, we'll bucket it with the primary constructor work we're doing in C# 12, which would put it in the working set. We'll rebucket to Any time if it doesn't end up fitting in that bucket.

Conclusion

Proposal is accepted, will be part of the primary ctor work in C# 12.