Fix typos in proposals (#1267)

proposals/auto-prop-field-attrs.md

@@ -13,7 +13,7 @@ This feature intends to allow developers to apply attributes directly to the bac
 ## Motivation
 [motivation]: #motivation
 
-Currently it is not possible to apply attributes to the backing fields of auto-implemented properties.  In those cases where the developer must use a field-targetting attribute they are forced to declare the field manually and use the more verbose property syntax.  Given that C# has always supported field-targetted attributes on the generated backing field for events it makes sense to extend the same functionality to their property kin.
+Currently it is not possible to apply attributes to the backing fields of auto-implemented properties.  In those cases where the developer must use a field-targeting attribute they are forced to declare the field manually and use the more verbose property syntax.  Given that C# has always supported field-targeted attributes on the generated backing field for events it makes sense to extend the same functionality to their property kin.
 
 ## Detailed design
 [design]: #detailed-design
@@ -28,7 +28,7 @@ public class Foo {
 }
 ```
 
-This would result in the field-targetted attributes being applied to the compiler-generated backing field:
+This would result in the field-targeted attributes being applied to the compiler-generated backing field:
 
 ```cs
 [Serializable]
@@ -59,7 +59,7 @@ public class Foo {
 There are two potential drawbacks to implementing this change:
 
 1. Attempting to apply an attribute to the field of an auto-implemented property produces a compiler warning that the attributes in that block will be ignored.  If the compiler were changed to support those attributes they would be applied to the backing field on a subsequent recompilation which could alter the behavior of the program at runtime.
-1. The compiler does not currently validate the AttributeUsage targets of the attributes when attempting to apply them to the field of the auto-implemented property.  If the compiler were changed to support field-targetted attributes and the attribute in question cannot be applied to a field the compiler would emit an error instead of a warning, breaking the build.
+1. The compiler does not currently validate the AttributeUsage targets of the attributes when attempting to apply them to the field of the auto-implemented property.  If the compiler were changed to support field-targeted attributes and the attribute in question cannot be applied to a field the compiler would emit an error instead of a warning, breaking the build.
 
 ## Alternatives
 [alternatives]: #alternatives

proposals/blittable.md

@@ -105,7 +105,7 @@ In the case there is a type named `unmanaged` and it is available without qualif
 
 The primary drawback of this feature is that it serves a small number of developers: typically low level library authors or frameworks.  Hence it's spending precious language time for a small number of developers. 
 
-Yet these frameworks are are often the basis for the majority of .NET applications out there.  Hence performance / correctness wins at this level can have a riple effect on the .NET ecosystem.  This makes the feature worth considering even with the limited audience. 
+Yet these frameworks are often the basis for the majority of .NET applications out there.  Hence performance / correctness wins at this level can have a ripple effect on the .NET ecosystem.  This makes the feature worth considering even with the limited audience.
 
 ## Alternatives
 [alternatives]: #alternatives
@@ -128,7 +128,7 @@ The F# language has a very [similar feature](https://docs.microsoft.com/en-us/do
 
 ### Verifier
 
-Does the verifier / runtime need to be updated to understad the use of pointers to generic type parameters?  Or can it simply work as is without changes. 
+Does the verifier / runtime need to be updated to understand the use of pointers to generic type parameters?  Or can it simply work as is without changes?
 
 **Resolution** No changes needed. All pointer types are simply unverifiable. 
 

proposals/caller-argument-expression.md

@@ -247,7 +247,7 @@ There are a few disadvantages of this approach:
 
 - Despite being pay-for-play friendly by allowing you to specify which properties you need, it could still hurt perf significantly by allocating an array for the expressions/calling `MethodBase.GetCurrentMethod` even when the assert passes.
 
-- Additionally, while passing a new flag to the `CallerInfo` attribute won't be a breaking change, `Debug.Assert` won't be guaranteed to actually receive that new parameter from call sites that compiled against an old verion of the method.
+- Additionally, while passing a new flag to the `CallerInfo` attribute won't be a breaking change, `Debug.Assert` won't be guaranteed to actually receive that new parameter from call sites that compiled against an old version of the method.
 
 ## Unresolved questions
 [unresolved]: #unresolved-questions

proposals/csharp-7.1/infer-tuple-names.md

@@ -7,7 +7,7 @@ In a number of common cases, this feature allows the tuple element names to be o
 
 This parallels the behavior of  anonymous types, which allow inferring member names during creation. For instance, `new { x.f1, y?.f2 }` declares members "f1" and "f2".
 
-This is particularily handy when using tuples in LINQ:
+This is particularly handy when using tuples in LINQ:
 
 ```
 // "c" and "result" have element names "f1" and "f2"

proposals/csharp-7.2/readonly-ref.md

@@ -31,7 +31,7 @@ The examples are numerous - vector/matrix math operators in graphics libraries l
 Similarly to the `out` parameters, `in` parameters are passed as managed references with additional guarantees from the callee.  
 Unlike `out` parameters which _must_ be assigned by the callee before any other use, `in` parameters cannot be assigned by the callee at all.
 
-As a result `in` parameters allow for effectiveness of indirect argument passing without exposing arguments to mutations by the calee.  
+As a result `in` parameters allow for effectiveness of indirect argument passing without exposing arguments to mutations by the callee.
 
 ## Declaring `in` parameters
 
@@ -407,7 +407,7 @@ In short - a feature that makes `this` parameter of all instance members of a st
 Compiler must assume that any method call on a struct instance may modify the instance. Indeed a writeable reference is passed to the method as `this` parameter and fully enables this behavior. To allow such invocations on `readonly` variables, the invocations are applied to temp copies. That could be unintuitive and sometimes forces people to abandon `readonly` for performance reasons.  
 Example: https://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields/
 
-After adding support for `in` parameters and `ref redonly` returns the problem of defensive copying will get worse since readonly variables will become more common.
+After adding support for `in` parameters and `ref readonly` returns the problem of defensive copying will get worse since readonly variables will become more common.
 
 ## Solution
 Allow `readonly` modifier on struct declarations which would result in `this` being treated as `in` parameter on all struct instance methods except for constructors.
@@ -566,7 +566,7 @@ static readonly ref Vector3 M1_Trace()
 Except for their `readonly` nature, `ref readonly` locals behave like ordinary `ref` locals and are subject to exactly same restrictions.  
 For example restrictions related to capturing in closures, declaring in `async` methods or the `safe-to-return` analysis equally applies to `ref readonly` locals.
 
-# Ternary `ref` expressons. (aka "Conditional LValues")
+# Ternary `ref` expressions. (aka "Conditional LValues")
 
 ## Motivation
 Use of `ref` and `ref readonly` locals exposed a need to ref-initialize such locals with one or another target variable based on a condition.
@@ -654,7 +654,7 @@ Can be used as a receiver of a method call and skip copying if necessary.
 ## Drawbacks
 [drawbacks]: #drawbacks
 
-I can see two major arguments against enhanced support for references and readonly refernces:
+I can see two major arguments against enhanced support for references and readonly references:
 
 1) The problems that are solved here are very old. Why suddenly solve them now, especially since it would not help existing code?
 

proposals/csharp-7.2/span-safety.md

@@ -44,7 +44,7 @@ An additional measure will be taken to prevent the use of ref-like structs in co
 
 Having no other good alternatives that work in old compilers without servicing, an `Obsolete` attribute with a known string will be added to all ref-like structs. Compilers that know how to use ref-like types will ignore this particular form of `Obsolete`.
 
-A typical matadata representation: 
+A typical metadata representation:
 
 ```C#
     [IsRefLike]
@@ -234,7 +234,7 @@ A stackalloc expression is an rvalue that is *safe-to-escape* to the top-level s
 
 A `new` expression that invokes a constructor obeys the same rules as a method invocation that is considered to return the type being constructed.
 
-In addition *safe-to-escape* is no wider than the smallest of the *safe-to-escape* of all arguments/operands of the object initializer expressons, recursively, if initializer is present. 
+In addition *safe-to-escape* is no wider than the smallest of the *safe-to-escape* of all arguments/operands of the object initializer expressions, recursively, if initializer is present. 
 
 ## `default` expressions
 

proposals/default-interface-methods.md

@@ -138,7 +138,7 @@ interface IB : IA
 
 Override declarations in interfaces may not be declared `sealed`.
 
-Public `virtual` function members in an interface may be overriden in a derived interface either implicitly (by using the `override` modifier in a public declaration in the derived interface) or explicitly (by qualifying the name in the override declaration with the interface type that originally declared the method, and omitting an access modifier).
+Public `virtual` function members in an interface may be overridden in a derived interface either implicitly (by using the `override` modifier in a public declaration in the derived interface) or explicitly (by qualifying the name in the override declaration with the interface type that originally declared the method, and omitting an access modifier).
 
 `virtual` function members in an interface that are not `public` may only be overridden explicitly (not implicitly) in derived interfaces, and may only be implemented in a class or struct explicitly (not implicitly). In either case, the overridden or implemented member must be *accessible* where it is overridden.
 

proposals/fixed-sized-buffers.md

@@ -59,7 +59,7 @@ Since such fixed-sized buffers no longer require use of `fixed`, it makes sense
 
 * There could be some challenges with backwards compatibility, but given that the existing fixed-sized buffers only work with a selection of primitive types, it should be possible for the compiler to continue "just-working" if the user treats the fixed-buffer as a pointer. 
 * Incompatible constructs may need to use slightly different `v2` encoding to hide the fields from old compiler.
-* Packing is not well defined in IL spec for generic types. While the approach should work, we will be bordering on undocumnted behavior. We should make that documented and make sure other JITs like Mono have the same behavior.
+* Packing is not well defined in IL spec for generic types. While the approach should work, we will be bordering on undocumented behavior. We should make that documented and make sure other JITs like Mono have the same behavior.
 * Specifying a separate type for every length (an possibly another for `readonly` fields, if supported) will have impact on metadata. It will be bound by the number of arrays of different sizes in the given app. 
 * `ref` math is not formally verifiable (since it is unsafe). We will need to find a way to update verification rules to know that our use is ok.