Small fixes to LDM notes (#383)

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

@@ -9,7 +9,7 @@ A few C# 7.0 issues to review.
 
 # Constant pattern semantics
 
-Issue #16513 proposes a change to the semantics of constant patterns in `is` expressions. For the code
+[Issue #16513](https://github.com/dotnet/roslyn/issues/16513) proposes a change to the semantics of constant patterns in `is` expressions. For the code
 
 ``` c#
 e is 42
@@ -37,7 +37,7 @@ Do it.
 
 # Extension methods on tuples
 
-Issue #16159 laments the facts that extension methods only apply to tuples if the tuple types match exactly. This is because extension methods currently only apply if there is an *identity, reference or boxing conversion* from the receiver to the type of the extension method's first parameter.
+[Issue #16159](https://github.com/dotnet/roslyn/issues/16159) laments the facts that extension methods only apply to tuples if the tuple types match exactly. This is because extension methods currently only apply if there is an *identity, reference or boxing conversion* from the receiver to the type of the extension method's first parameter.
 
 The spirit of this rule is that if it applies to a type or its bases or interfaces, it will work. We agree that it *feels* like it should also work for tuples - at least "sometimes". We cannot make it just always work for tuple conversions, though, since they may recursively apply all kinds of conversions, including user defined conversions.
 

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

@@ -31,6 +31,7 @@ Candidate for VB 16.
 
 # Delegate and enum constraints
 [Champion "Generic constraint `delegate` (or allow `System.Delegate` as a constraint)"](https://github.com/dotnet/csharplang/issues/103)
+
 [Champion "Generic constraint `enum` (or allow `System.Enum` as a constraint)"](https://github.com/dotnet/csharplang/issues/104)
 
 This is a common request. Could
@@ -75,6 +76,7 @@ Candidate for a minor C# release in the 7.X wave.
 
 # Null-coalescing assignments and awaits
 [Champion "Null-coalescing assignments"](https://github.com/dotnet/csharplang/issues/34)
+
 [Champion "Null-conditional await"](https://github.com/dotnet/csharplang/issues/35)
 
 These need a little more design work and general bake time than what 7.1 allows.

meetings/2017/LDM-2017-02-22.md

@@ -33,7 +33,7 @@ Support `readonly` just on whole struct types for now, until and unless evidence
 We've been calling this feature "readonly ref", but it is really not the ref that is readonly; rather it is the thing that is referenced. For that reason is more correct to call it `ref readonly`, as in:
 
 ``` c#
-public ref readonly Choose(ref readonly int i1, ref readonly int i2) { ... }
+public ref readonly int Choose(ref readonly int i1, ref readonly int i2) { ... }
 ```
 
 Currently, refs *themselves* are always single-assignment in C#, but if we decide at some point to make them reassignable by default (which we could do without breaking), then you might want to be able to *explicitly* put a `readonly` modifier on the refs themselves. That would be `readonly ref`. And of course you could have `readonly ref readonly` where both the ref and the target are readonly.
@@ -43,7 +43,7 @@ Currently, refs *themselves* are always single-assignment in C#, but if we decid
 `ref readonly` is a bit of a mouthful. For parameters, `ref readonly` is in fact the exact opposite of `out`: something that comes in but cannot be modified. It would make total sense to call them `in` parameters. However, it would probably be confusing to call a *return* value `in`, so `in` should be allowed as a shorthand for `ref readonly` exclusively on parameters.
 
 ``` c#
-public ref readonly Choose(in int i1, in int i2) { ... } // Equivalent to the above
+public ref readonly int Choose(in int i1, in int i2) { ... } // Equivalent to the above
 ```
 
 ## Call site annotations

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

@@ -10,7 +10,7 @@
 
 # Conditional operator over refs
 
-[github.com/dotnet/csharplang/issues/223](https://github.com/dotnet/csharplang/issues/223)
+[Champion "conditional ref operator"](https://github.com/dotnet/csharplang/issues/223)
 
 Choice between two variables is not easily expressed, even with ref returns. 
 
@@ -79,7 +79,7 @@ There are subtle differences between the current spec and implementation when it
 
 # Async Main
 
-[github.com/dotnet/csharplang/issues/97](https://github.com/dotnet/csharplang/issues/97)
+[Champion "Async Main"](https://github.com/dotnet/csharplang/issues/97)
 
 We want to allow program entry points (`Main` methods) that contain `await`. The temptation is to allow the `async` keyword on existing entry points returning `void` (or `int`?). However, that makes it *look* like an `async void` method, which is fire-and-forget, whereas we actually want program execution to wait for the main method to finish. So we'd have to make it so that if the method is invoked as an *entry* point we (somehow) wait for it to finish, whereas if it's invoked by another method, it is fire-and-forget.
 
@@ -106,4 +106,4 @@ C# 7.0 allows declaration of other "tasklike" types. We won't allow those in ent
 
 ## Conclusion
 
-Allow `Task` and `Task<int>` returning `Main` methods as entry points, invoking as `Main(...).GetAwaiter().GetResult()`.
+Allow `Task` and `Task<int>` returning `Main` methods as entry points, invoking as `Main(...).GetAwaiter().GetResult()`.

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

@@ -80,7 +80,7 @@ In other languages `()` are list-like unit type things.
 
 Also if we ever go to bool-returning Deconstruct methods (or the like), you might want zero-length decosntructors to mean "there wasn't anything".
 
-Womples are more likely to be useful, especially for deconstruction. But they are also the ones that vlash most fiercely with existing syntax (parenthesized expressions!).
+Womples are more likely to be useful, especially for deconstruction. But they are also the ones that clash most fiercely with existing syntax (parenthesized expressions!).
 
 ``` c#
 () t = ();