# C# Language Design Meeting for March 13th, 2023

## Agenda

- [Unsafe in aliases hole](#unsafe-in-aliases-hole)
- [Attributes on primary ctors](#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 `using`s in general, and do not require them for `unsafe` types in `using`s.

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.
