Fix typos in meetings (#1268)

meetings/2014/LDM-2014-01-06.md

@@ -12,7 +12,7 @@ There are a couple of places where declaration expressions are grammatically amb
 
 There are two kinds of full ambiguities (i.e. ones that don’t resolve with more lookahead):
 ``` c#
-a * b // multiplication expression or unitialized declaration of pointer?
+a * b // multiplication expression or uninitialized declaration of pointer?
 a < b > c // nested comparison or uninitialized declaration of generic type?
 ```
 The latter one exists also in a method argument version that seems more realistic:

meetings/2014/LDM-2014-02-03.md

@@ -40,7 +40,7 @@ The best way for us to deal with this is to simply disallow automatic capture. T
     }
 ```
 
-Now this raises a new problem. What if you want to capture a constructor parameter in a private field and have no intention of exposing it publically. You can do that explicitly:
+Now this raises a new problem. What if you want to capture a constructor parameter in a private field and have no intention of exposing it publicly. You can do that explicitly:
 
 ``` c#
 public class Person(string first, string last)

meetings/2014/LDM-2014-07-09.md

@@ -28,7 +28,7 @@ The notion of referenced set has little importance for the language-level semant
 Reference to some entities, e.g. obsolete members, `Finalize` or ‘`op_`’ methods, is normally an error. However, it is not an error in `nameof(…)` unless _all_ members of the referenced set would give an error. If all non-error references give warnings, then a warning is given.
 
 ### The resulting string
-C# doesn’t actually have a notion of canonical name. Instead, equality between names is currently defined directly _beween_ names that may contain special symbols.
+C# doesn’t actually have a notion of canonical name. Instead, equality between names is currently defined directly _between_ names that may contain special symbols.
 
 For `nameof(… i)` we want the resulting string to be the identifier `I` given, except that formatting characters are omitted, and Unicode escapes are resolved. Also, any leading `@` is removed.
 

meetings/2014/LDM-2014-10-01.md

@@ -73,11 +73,11 @@ Class C
 
     Public Sub New()
         f(x)
-        Dim lamda = Sub()
-                        f(x) ' error BC36602: 'ReadOnly' variable
-                        ' cannot be the target of an assignment in a lambda expression
-                        ' inside a constructor.
-                    End Sub
+        Dim lambda = Sub()
+                         f(x) ' error BC36602: 'ReadOnly' variable
+                         ' cannot be the target of an assignment in a lambda expression
+                         ' inside a constructor.
+                     End Sub
     End Sub
     Shared Sub f(ByRef x As Integer)
         x = 23
@@ -102,7 +102,7 @@ __Workarounds__
 4. Write documentation for the interface, on MSDN or in XML Doc-Comments, that say "Internal class only; do not implement it". We see this for instance on ICorThreadpool.
 5. Declare a method on the interface which has an internal type in its signature. The CLR allows this but the language doesn't so it would have to be authored in IL. Every type which implements the interface would have to provide an implementation of that method.
 6. Write run-time checks at the public entry points of key Roslyn methods that take in an ISymbol, and throw if the object given was implemented in the wrong assembly.
-7. Write a Roslyn analyzer which is deployed by the same Nuget package that contains the definition of ISymbol, and have this analyzer warn if you're trying to implement the interface. This analyzer could be part of Roslyn, or it could be an independent third-party analyzer used by many libraries.
+7. Write a Roslyn analyzer which is deployed by the same NuGet package that contains the definition of ISymbol, and have this analyzer warn if you're trying to implement the interface. This analyzer could be part of Roslyn, or it could be an independent third-party analyzer used by many libraries.
 
 
 __Proposal:__ Have the compiler recognize a new attribute. Given the following code

meetings/2015/LDM-2015-01-21.md

@@ -195,7 +195,7 @@ Metaprogramming
 
 Metaprogramming has been around as a theme on the radar for a long time, and arguably Roslyn is a big metaprogramming project aimed at writing programs about programs. However, at the language level we continue not to have a particularly good handle on metaprogramming. 
 
-Extention methods and partial classes both feel like features that could grow into allowing *generated* parts of source code to merge smoothly with *hand-written* parts. But if generated parts are themselves the result of language syntax - e.g. attributes in source code, then things quickly get messy from a tooling perspective. A keystroke in file A may cause different code to be generated into file B by some custom program, which in turn may change the meaning of A. Not a feedback loop we're eager to have to handle in real time at 20 ms keystroke speed!
+Extension methods and partial classes both feel like features that could grow into allowing *generated* parts of source code to merge smoothly with *hand-written* parts. But if generated parts are themselves the result of language syntax - e.g. attributes in source code, then things quickly get messy from a tooling perspective. A keystroke in file A may cause different code to be generated into file B by some custom program, which in turn may change the meaning of A. Not a feedback loop we're eager to have to handle in real time at 20 ms keystroke speed!
 
 Oftentimes the eagerness to generate source comes from it being too hard to express your concept beautifully as a library or an abstraction. Increasing the power of abstraction mechanisms in the language itself, or just the syntax for applying them, might remove a lot of the motivation for generated boilerplate code.
 

meetings/2015/LDM-2015-01-28.md

@@ -71,7 +71,7 @@ As a case study, has Roslyn suffered from the lack of this feature? There have b
 
 Probably not. Roslyn is *not* immutable. It's presenting an immutable *view*, but is mutable inside. Would that be the common case, though? 
 
-Some of the "cheating" in Roslyn (caching, free lists, etc) is for performance, some is for representing cycles. Insofar as the immutable types feature is *also* for performance, it seems that thhere's a tension between using it or not.
+Some of the "cheating" in Roslyn (caching, free lists, etc) is for performance, some is for representing cycles. Insofar as the immutable types feature is *also* for performance, it seems that there's a tension between using it or not.
 
 In summary, we are unsure of the value. Let's talk more.
 
@@ -136,7 +136,7 @@ if (e != null) {
     var a = e.Expr as AssignmentExpressionSyntax;
     if (a != null) {
         var l = a.Left as IdentifierName;
-        var r = a.RIght as IdentifierName;
+        var r = a.Right as IdentifierName;
         if (l != null && r != null & l.Name.name == r.Name.name) ...
 ```
 

meetings/2015/LDM-2015-03-18.md

@@ -20,7 +20,7 @@ In this meeting we looked over the top [C# language feature requests on UserVoic
 8. XML comments (*Not a language request*) 
 9. Unmanaged constraint (*requires CLR support*)
 10. Compilable strings (*this is what nameof is for*)
-11. Mulitple returns (*working on it, via tuples*)
+11. Multiple returns (*working on it, via tuples*)
 12. ISupportInitialize (*too specific; hooks on object initializers?*)
 13. ToNullable (*potentially part of nullability support*)
 14. Statement lambdas in expression trees (*fair request, big feature!*)
@@ -125,7 +125,7 @@ This would be great in order to enable pointers over type parameters. However, i
 This is mostly addressed by `nameof` in C# 6; it's unlikely there is basis for more language level functionality here.
 
 
-11\. Mulitple returns
+11\. Multiple returns
 =====================
 
 [http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2083753-return-multiple-values-from-functions-effortlessly](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2083753-return-multiple-values-from-functions-effortlessly)

meetings/2015/LDM-2015-04-14.md

@@ -18,7 +18,7 @@ In a typical scenario a lambda expression tree is produced in one place, ideally
 
 Along the way, several transformations are often made on the trees, for efficiency reasons etc. For instance, rather than invoke a lambda its body can often be inlined in the enclosing tree that the lambda gets stitched into.
 
-The serialization format is able to carry very specific type information along with the code, but can also represent the code loosely. A looser coupling makes for code that is more resilient to "schema" differences between the nodes, and also allows for use of types and functions that aren't present where the lambda is concocted. However, it also makes it harder to stich things back up right on the other side.
+The serialization format is able to carry very specific type information along with the code, but can also represent the code loosely. A looser coupling makes for code that is more resilient to "schema" differences between the nodes, and also allows for use of types and functions that aren't present where the lambda is concocted. However, it also makes it harder to stitch things back up right on the other side.
 
 
 

meetings/2015/LDM-2015-08-18.md

@@ -12,7 +12,7 @@ A summary of the design we (roughly) landed on in #5031 was put out on GitHub as
 
 # Array creation with non-nullable types
 
-For array creation there is the question whether to allow (big hole) or disallow (big nuisance?) on non-nullable referance types. We'll leave it at allow for now, but may reconsider.
+For array creation there is the question whether to allow (big hole) or disallow (big nuisance?) on non-nullable reference types. We'll leave it at allow for now, but may reconsider.
 
 # Null checking operator
 

meetings/2015/LDM-2015-09-01.md

@@ -92,7 +92,7 @@ On closer scrutiny, though, this scenario does raise harder issues. If you use a
 
 These are questions we don't want to answer right now for a somewhat hypothetical scenario.
 
-**Conclusion**: for the propotype, ref locals are non-reassignable, and get their "safe-to-return" status from their mandatory ref initializer.
+**Conclusion**: for the prototype, ref locals are non-reassignable, and get their "safe-to-return" status from their mandatory ref initializer.
 
 If there are scenarios not covered by this, we'll discover as folks start using the prototype and tell us.
 

meetings/2015/LDM-2015-09-02.md

@@ -35,7 +35,7 @@ We like this.
 What do branches mean
 =====================
 
-As prototypes start to come online, we need to decide how we use our pbranches. The Future branch is for when things are at prototype level for the whole experience - including IDE. Features will be guarded by a feature flag until it's the confident plan of record to ship the feature in its current form.
+As prototypes start to come online, we need to decide how we use our branches. The Future branch is for when things are at prototype level for the whole experience - including IDE. Features will be guarded by a feature flag until it's the confident plan of record to ship the feature in its current form.
 
 We are working on enabling VSIXes to change the language model in the IDE without the need for customers to install over VS. Hopefully this capability will be available in an update to VS in a not too distant future. Once that is in place, we can ship prototypes that run without risk to customers' VS installation.
  

meetings/2015/LDM-2015-09-08.md

@@ -116,7 +116,7 @@ Along with this, we'd need to consider whether to extend the query syntax in the
 
 ## Language support
 
-In the language we would add support for foreach'ing over async sequences to consume them, and for async iterators to produce them. Additionally (we don't discuss that further here) we may want to introduce a notion of `IAsyncDisposable`, for weach we could add an async version of the `using` statement.
+In the language we would add support for foreach'ing over async sequences to consume them, and for async iterators to produce them. Additionally (we don't discuss that further here) we may want to introduce a notion of `IAsyncDisposable`, for which we could add an async version of the `using` statement.
 
 One concern about async versions of language features such as foreach (and using) is that they would generate `await` expressions that aren't there in source. Philosophically that may or may not be a problem: do you want to be able to see where all the awaiting happens in your async method? If that's important, we can maybe add the `await` or `async` keyword to these features somewhere:
 

meetings/2015/LDM-2015-10-07-Design-Review.md

@@ -44,7 +44,7 @@ resort.
 - One issue around user-defined conversions to switchable types is
 resolved (https://github.com/dotnet/roslyn/issues/4944). In the draft spec,
 a conversion will be applied on the `case`s, not on the control-expression unilaterally.
-Instead of converting only to `swithable` types, each
+Instead of converting only to `switchable` types, each
 `case` arm will consider any conversions that allow the `case` to be applied.
 Any given conversion would be applied at most once. 
 

meetings/2015/README.md

@@ -81,7 +81,7 @@ In this meeting we looked over the top [C# language feature requests on UserVoic
 8. XML comments (*Not a language request*) 
 9. Unmanaged constraint (*requires CLR support*)
 10. Compilable strings (*this is what nameof is for*)
-11. Mulitple returns (*working on it, via tuples*)
+11. Multiple returns (*working on it, via tuples*)
 12. ISupportInitialize (*too specific; hooks on object initializers?*)
 13. ToNullable (*potentially part of nullability support*)
 14. Statement lambdas in expression trees (*fair request, big feature!*)

meetings/2016/LDM-2016-02-29.md

@@ -127,7 +127,7 @@ p.With("Minney", p.LastName)
 
 We can decide whether to make with-expressions _require_ a `With` method, or fall back to constructor calls in its absence.
 
-If we _require_ a `With` method, that makes for less interoperability with existing types. However, it gives us new opportunities for how to provide the position/name mapping metadata thorugh the declaration of that `With` method: For instance, we could introduce a new kind of default parameter that explicitly wires the parameter to a property:
+If we _require_ a `With` method, that makes for less interoperability with existing types. However, it gives us new opportunities for how to provide the position/name mapping metadata through the declaration of that `With` method: For instance, we could introduce a new kind of default parameter that explicitly wires the parameter to a property:
 
 ``` c#
   public abstract Person With(string firstName = this.FirstName, string lastName = this.LastName);

meetings/2016/LDM-2016-07-13.md

@@ -84,7 +84,7 @@ We think no. the existence of a `Deconstruct` method should not imply conversion
 
 We could consider letting user defined implicit conversion imply `Deconstruct`. It leads to some convenience, but makes for a less clean correspondence with consumption code.
 
-Let's keep it separate. If you want a type to be both deconstructible and convertible to tuple, you need to specify both.
+Let's keep it separate. If you want a type to be both deconstructable and convertible to tuple, you need to specify both.
 # Anonymous types
 
 Should they implement `Deconstruct` and `ITuple`, and be convertible to tuples?

meetings/2016/LDM-2016-11-01.md

@@ -58,7 +58,7 @@ Should we make existing types "span-aware"? Arrays? Strings?
 We need to figure out what the right trade-off is.  
 
 
-Generally we would keep Span<T> at the 1% of users. It's analogous to array in the sense that it's arerely used directly in higher-level code.
+Generally we would keep Span<T> at the 1% of users. It's analogous to array in the sense that it's rarely used directly in higher-level code.
 
 For the rest there's wrapper types that are not limited to the stack, and can go into Span-land on demand.
 
@@ -155,7 +155,7 @@ Limitations around ref locals today
 
 There are many limitations to keep the rules simple, including the fact that ref locals are readonly at the ref level.
 
-What should the restrictions be around ref-like types? One difference is thate.g. Span has a default value; 0-length span.
+What should the restrictions be around ref-like types? One difference is that e.g. Span has a default value; 0-length span.
 
 
 Next steps

meetings/2017/LDM-2017-01-11.md

@@ -82,7 +82,7 @@ When there are expression variables in the case header, in the case body forbid:
 Drop the subbullets for now, and maybe we can relax later
 
 
-Out of all these approaches, we still think expanding the lifeltime (but not the scope) has the lowest risk. Fallout work is likely in the debugger, which will have a suboptimal experience in these scenarios. THis work is probably puntable.
+Out of all these approaches, we still think expanding the lifetime (but not the scope) has the lowest risk. Fallout work is likely in the debugger, which will have a suboptimal experience in these scenarios. This work is probably puntable.
 
 
 

meetings/2017/LDM-2017-01-18.md

@@ -13,7 +13,7 @@ Can't have an enumerator be shared between multiple threads.
 
 You can imagine channel-like data sources that provide enumerators but each enumerator gets a distinct set of values.
 
-The interface is just giving you an access pattern, not a contract. They could be "hot" or "cold" / repeatedable or not.
+The interface is just giving you an access pattern, not a contract. They could be "hot" or "cold" / repeatable or not.
 
 Should we be close to Channel or is that something else?
 

meetings/2017/LDM-2017-03-01.md

@@ -77,8 +77,8 @@ There's also a more implementation-oriented issue:
 
 When generating code for an await, we need to "spill" the stack, including any variable refs sitting on it, to the heap. Since refs cannot be in the heap, we do tricks: since we know the variable may need spilling, we don't actually resolve it in place. Instead we keep around the constituent parts (e.g. an array and an index, an object and a member, etc) and only look it up *after* the code has resumed after the await.
 
-But here we cannot easily store the constituent parts, because we won't know which branch of the conditional will end up getting executed, and each may lead to different forms of constituent parts! While there may be extremely sneaky and possibly expensive ways around this, we could also just forbid the await. However, the error message would be very strange indeed if it came on an ordinary shape of conditional, whereas it is easier to say refering to a special syntactic form of the conditional.
+But here we cannot easily store the constituent parts, because we won't know which branch of the conditional will end up getting executed, and each may lead to different forms of constituent parts! While there may be extremely sneaky and possibly expensive ways around this, we could also just forbid the await. However, the error message would be very strange indeed if it came on an ordinary shape of conditional, whereas it is easier to say referring to a special syntactic form of the conditional.
 
 ## Conclusion
 
-On the whole, these challenges lead us to prefer the original proposal with the explicit occurences of `ref` in the syntax. 
+On the whole, these challenges lead us to prefer the original proposal with the explicit occurrences of `ref` in the syntax. 

meetings/2017/LDM-2017-03-15.md

@@ -56,7 +56,7 @@ Attributes on lambdas seem like a more general feature. Let's feed this in as a
 
 Best approach is the small leak pattern which creates a wrapper delegate with a weak reference to the original receiver. That doesn't solve the whole problem, though - how about unregistering, etc?
 
-This isn't necessarily a language feature. This should be a library that you pass the method to, and it wraps it. It would be helped by the langauge allowing for a delegate constraint.
+This isn't necessarily a language feature. This should be a library that you pass the method to, and it wraps it. It would be helped by the language allowing for a delegate constraint.
 
 Conclusion: Not as a language feature right now; figure it out as a library feature, and *maybe*, someday we would add syntax around it.
 

meetings/2017/LDM-2017-03-21.md

@@ -21,7 +21,7 @@ Discussion of default interface member implementations, based on [this guided to
 
 # Concerns raised in various fora
 
-- Traits: Not what we're out to address! It may have similar capabilites, but the design point is different, based on different motivations.
+- Traits: Not what we're out to address! It may have similar capabilities, but the design point is different, based on different motivations.
 - We are also *not* out to add multiple inheritance to the language - we already have it with interfaces, and we're just making sure that continues to work.
 - It's a bit funny that members of interfaces are inherited into interfaces but not into classes.
 

meetings/2017/LDM-2017-08-07.md

@@ -138,7 +138,7 @@ This is expected to come with heavy tooling costs, because we need to wire throu
 
 ## Library self-opt-in
 
-This approach lets the library express, through attributes, whether to consider its unnanotated types non-nullable. The default would be no, so that an existing nullability-unaware library would continue working as it does today, i.e. lead to no warnings.
+This approach lets the library express, through attributes, whether to consider its unannotated types non-nullable. The default would be no, so that an existing nullability-unaware library would continue working as it does today, i.e. lead to no warnings.
 
 We sometimes call this option "URTANN" because the meaning of the attribute is "**U**nannotated **R**eference **T**ypes **A**re **N**on-**N**ullable".
 

meetings/2017/LDM-2017-08-16.md

@@ -33,7 +33,7 @@ We could generalize `!` to silencing all nullability warnings even in subexpress
 
 If `!` is applied in a place that yields no nullability warnings, does that lead to a warning? No. We don't want to create a new source of warnings caused by a warning-suppressing operator! There is a legit scenario, which is to clean up superfluous "!"s when a depended-upon API gets properly annotated. But this seems more the province of analyzers or similar tools.
 
-We can make `!!` an error. If you really want two conecutive bangs (we don't believe there's *any* scenario, other than swearing) you can parenthesize: `(e!)!`.
+We can make `!!` an error. If you really want two consecutive bangs (we don't believe there's *any* scenario, other than swearing) you can parenthesize: `(e!)!`.
 
 An alternative is to make the type of `e!` oblivious, if we choose to embrace a notion of oblivious. That's attractive in that it makes a type for "something that doesn't yield warnings", but it's also viral - could lead to many things not being checked. It's an option to be considered in future.
 

meetings/2017/LDM-2017-08-28.md

@@ -16,7 +16,7 @@ The fact that span is array like is not very interesting for the safety rules. T
 
 Once you can embed refs in struct, the question: How can you assign them?
 
-With assigment, you can now assign to ref parameters of ref-like structs, so every assignment is a potential return.
+With assignment, you can now assign to ref parameters of ref-like structs, so every assignment is a potential return.
 
 "Let's not refer to local data" does not work here:
 

meetings/2017/LDM-2017-10-09.md

@@ -21,7 +21,7 @@ Put it in X.X with a note to consider again when we have match expressions
 
 There's a "there" there.
 
-We think this should be addressed, and will keep the chanpioning issue to represent it.
+We think this should be addressed, and will keep the championing issue to represent it.
 
 However, it should be different:
 

meetings/2017/LDM-2017-10-18.md

@@ -74,7 +74,7 @@ For now, let's put it in 8.0. We don't believe it's going to make 7.3, but that
 
 # 179
 
-For people who care about perf, they already need 3 or 4 overloads, and this would be yet another overload peopple will yell at them to add.
+For people who care about perf, they already need 3 or 4 overloads, and this would be yet another overload people will yell at them to add.
 
 For no parameters today, you no longer need an overload to avoid allocation, because we now use `Array.Empty`.
 

meetings/2017/LDM-2017-10-25.md

@@ -103,7 +103,7 @@ It's a zero-conceptual-overhead feature.
 
 Original designers left in space between meanings for a purpose. But that's not so compelling to us anymore.
 
-Because it touches overload resolution, it might be better alligned with a .0 release. But we're not compelled by that.
+Because it touches overload resolution, it might be better aligned with a .0 release. But we're not compelled by that.
 
 Let's keep it, but again, it's cuttable.
 

meetings/2017/LDM-2017-11-29.md

@@ -47,7 +47,7 @@ Should it be a verb/command? Not many expression keywords are that (`select` is
             };
 ```
 
-The last one is subject to ambiguity-like situations betyween expression and statement `switch`.
+The last one is subject to ambiguity-like situations between expression and statement `switch`.
 
 We should also consider nesting of match expressions.