- "Oh my head hurts" "I'm glad I achieved my goal"
Last time 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.
Anonymous inline arrays are rejected. Array initializers are not supported for inline arrays. Collection literals are supported for inline arrays.
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.
The language will support using the new locking pattern for locking on System.Lock.