Fix typos (#7169)

meetings/2023/LDM-2023-05-01.md

@@ -20,7 +20,7 @@ https://github.com/dotnet/csharplang/issues/1314
 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, ease it slots into the language is almost an issue in itself; inline arrays
+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
@@ -37,13 +37,13 @@ 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 array.s
+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 alternative to monitor-based locks. The API has a shape that
+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

meetings/2023/LDM-2023-05-03.md

@@ -24,7 +24,7 @@ validating `InlineArrayAttribute` applications and whether nested object initial
 arrays. For the former, we're unanimously in favor of the compiler validating that the attribute was applied correctly.
 The latter proved to be a more interesting conversation; we brought up that arrays are supported, but this actually
 appears to be a spec violation of the C# compiler, as the syntax is supposed to require an indexer member to be defined
-on the type being initalized while arrays do not define any such member. We also don't think there's any real demand for
+on the type being initialized while arrays do not define any such member. We also don't think there's any real demand for
 this to be natively supported, and by leaving it out users can opt into the feature by defining their own indexer on
 their inline array types. This allows us to have our cake and eat it too: no implementation complexity for us, and users
 can get the syntax they choose if they want it.
@@ -84,7 +84,7 @@ segments are going to be surprised by the decision.
 So what if we didn't have a natural type at all? Today, users always need to think about the type of a collection when
 it is created. Either it needs to be assigned to a local or parameter that has a type, or it's being created by some
 factory method or constructor that has to be typed. One of the goals of the proposal to simplify this, and that requires
-having a natural type. But it does feel odd that, for a proposal that goes so far to be optimal when we know what the
+having a natural type. But it does feel odd that, for a proposal that goes so far to be optimal when we know the
 target type, it cannot be optimal in the natural type case. For the cohort of users that want these to be immutable,
 any mutability in the natural type means that the literals cannot be cached, resulting in lots of extra allocations. For
 those that expect an array, using `List<>` or some other similar type means that extra overhead is incurred, and trivial