# C# Language Design Meeting for May 1st, 2023

## Agenda

- [Fixed Size Buffers](#fixed-size-buffers)
- [`lock` statement improvements](#lock-statement-improvements)

## Quote of the Day

- "Oh my head hurts" "I'm glad I achieved my goal"

## Discussion

### Fixed Size Buffers

https://github.com/dotnet/csharplang/pull/7130  
https://github.com/dotnet/csharplang/issues/1314

[Last time](LDM-2023-04-10.md#fixed-size-buffers) we discussed fixed size buffers, we concluded
that we wanted to support manually defined inline array types in the language natively. This means, for example,
being able to index them. Our next question is, should we support anonymous inline array types? The proposed syntax
is `int[4]` for an anonymous inline array of 4 integers; this aligns well with existing array types in the language
and is a natural extension. However, the ease with which it slots into the language is almost an issue in itself; inline arrays
are not regular arrays and cannot be used where arrays can be. They do not unify across assemblies, and indeed the
proposal forbids making them public at all. There are also concerns on what the syntax will end up looking like with
nested arrays: a regular array of 4 element int arrays would end up looking like `int[][4]`. This is then complicated
further by nullability: a non-null regular array of 4 element int nullable arrays would be `int[]?[4]`. There are even
potential issues with `foreach`: an `int[4]` is only indexable via `Span`, which would potentially break usage in async
methods. Given all of these hidden gotchas and the lack of demand for anonymous inline arrays, we think the best
approach for now is to avoid having them at all.

We also looked at initialization scenarios; the main questions here are whether we allow array initializers for these
values, and whether we allow C# 12 collection literals for them. For array initializers, we think the answer should be
no, as we have now said there are no anonymous inline arrays. We do think that collection literals are the future here,
and they should work for inline arrays as well as other types of collections.

#### Conclusion

Anonymous inline arrays are rejected. Array initializers are not supported for inline arrays. Collection literals are
supported for inline arrays.

### `lock` statement improvements

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

The runtime will be adding a new `System.Lock` type, as an alternative to monitor-based locks. The API has a shape that
works well with `using`, but as it currently stands it will misbehave with a standard `lock` statement. This isn't the
first type of lock this is true for; for example, `ReaderWriterLock`/`ReaderWriterLockSlim`/`SpinLock`. However, this
is different in that all of those have caveats to their using with a regular `lock` statement: rwlocks need to enter
in a specific mode that can't be inferred from just a `lock` statement, and `SpinLock` is very rarely used. This new
type, on the other hand, is part of an experiment to entirely replace monitor-based locks in .NET, and the hope is
that new development will use these instead of an `object` to perform mutual exclusion. Given that, having it do the
wrong thing in a `lock` seems like an easy footgun for the language to solve. An open question is whether we want to
convince people to avoid monitor-based locks entirely; that seems like it would be best driven by the runtime, rather
than the language design team.

#### Conclusion

The language will support using the new locking pattern for locking on `System.Lock`.
