fix: MD033/no-inline-html

Inline HTML get swallowed in MD and HTML rendering

meetings/2013/LDM-2013-10-21.md

@@ -1,8 +1,8 @@
 # C# Design Notes for Oct 21, 2013
 ## Agenda
 Primary constructors is the first C# 6.0 feature to be spec’ed and implemented. Aleksey, who is doing the implementing joined us to help settle a number of details that came up during this process. We also did a rethink around Lightweight Dynamic.
-1.	Primary Constructors <fleshed out a few more details>
-2.	Lightweight Dynamic <we examined a much simpler approach>
+1.	Primary Constructors \<fleshed out a few more details>
+2.	Lightweight Dynamic \<we examined a much simpler approach>
 
 ## Primary Constructors
 

meetings/2013/LDM-2013-11-04.md

@@ -1,9 +1,9 @@
 # C# Design Notes for Nov 4, 2013
 ## Agenda
 Next up for implementation are the features for auto-properties and function bodies, both of which go especially well with primary constructors. For the purpose of spec’ing those, we nailed down a few remaining details. We also took another round discussing member access in the lightweight dynamic scenario.
-1. Initialized and getter-only auto-properties <details decided>
-2. Expression-bodied function members <details decided>
-3. Lightweight dynamic <member access model and syntax discussed>
+1. Initialized and getter-only auto-properties \<details decided>
+2. Expression-bodied function members \<details decided>
+3. Lightweight dynamic \<member access model and syntax discussed>
 
 ## Initialized and getter-only auto-properties
 We are allowing initializers for auto-properties, and we are allowing getter-only auto-properties, where the underlying field is untouched after the initializer has run. This was last discussed on May 20, and allows declarations like this:
@@ -98,4 +98,4 @@ Some principles emerge from this exercise:
 - What comes after that real dot really matters!
 
 ### Conclusion
-We like the “dot-like” syntax approach to LW dynamic member access, and we think it should be of the form x.<glyph>Foo for some value of <glyph>.
+We like the “dot-like” syntax approach to LW dynamic member access, and we think it should be of the form x.\<glyph>Foo for some value of \<glyph>.

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

@@ -54,7 +54,7 @@ __Out/ref arguments in C#__. Can you pass a readonly autoprop as an out/ref argu
 _Resolution: No_. For readonly autoprops passed as _ref_ arguments, that wouldn't obey the principle that access to the prop goes via its accessor. For passing readonly autoprops as _out_ arguments with the hope that it writes to the underlying field, that wouldn't obey the principle that we bind to the property rather than the backing field. For writeonly autoprops, they don't exist because they're not useful.
 
 __Static readonly autoprops__ Should everything we've written also work for static readonly autoprops?
-_Resolution: Yes._ Note there's currently a bug in the native compiler (fixed in Dev14) where the static constructor of a type G<T> is able to initialize static readonly fields in specializations of G e.g. `G<T>.x=15;`. The CLR does indeed maintain separate storage locations for each static readonly fields, so `G<int>.g` and `G<string>.g` are different variables. (The native compiler's bug where the static constructor of G could assign to all of them resulted in unverifiable code).
+_Resolution: Yes._ Note there's currently a bug in the native compiler (fixed in Dev14) where the static constructor of a type G\<T> is able to initialize static readonly fields in specializations of G e.g. `G<T>.x=15;`. The CLR does indeed maintain separate storage locations for each static readonly fields, so `G<int>.g` and `G<string>.g` are different variables. (The native compiler's bug where the static constructor of G could assign to all of them resulted in unverifiable code).
 
 __VB rules in initializers as well as constructors__. VB initializers are allowed to refer to other members of a class, and VB initializers are all executed during construction time. Should everything we've said about behavior in C# constructors also apply to behavior in VB initializers?
 _Resolution: Yes_.

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

@@ -21,7 +21,7 @@ This particular "nameof v5" proposal came from a combined VB + C# LDM on 2014.10
 3. __Allow to name method-groups? Yes.__ Settled on the answer "yes", based on the evidence that v1/v2 had it and it worked nicely, and v3 lacked it and ended up with unacceptably ugly constructions to select which method overload.
 4. __Allow to unambiguously select a single overload? No.__ Settled on the answer "no" based on the evidence that v3 let you do this but it looked too confusing. I know people want it, and it would be a stepping stone to infoof, but at LDM we rejected these (good) reasons as not worth the pain. The pain is that the expressions look like they'll be executed, and it's unclear whether you're getting the nameof the method or the nameof the result of the invocation, and they're cumbersome to write.
 5. __Allow to use nameof(other-nonexpression-types)? No.__ Settled on the answer "only nameof(expression)". I know people want other non-expression arguments, and v1/v2 had them, and it would be more elegant to just write nameof(List<>.Length) rather than having to specify a concrete type argument. But at LDM we rejected these (good) reasons as not worth the pain. The pain is that the language rules for member access in expressions are too different from those for member access in the argument to nameof(.), and indeed member access for StrongBox<>.Value.Length doesn't really exist. The effort to unify the two concepts of member access would be way disproportionate to the value of nameof. This principle, of sticking to existing language concepts, also explains why v5 uses the standard language notions of "member lookup", and hence you can't do nameof(x.y) to refer to both a method and a type of name "y" at the same time.
-6. __Use source names or metadata names? Source.__ Settled on source names, based on the evidence... v1/v2/v3 were source names because that's how we started; then we heard feedback that people were interested in metadata names and v4 explored metadata names. But I think the experiment was a failure: it ended up looking like _disallowing_ nameof on types was better than picking metadata names. At LDM, after heated debate, we settled on source names. For instance `using foo=X.Y.Z; nameof(foo)` will return "foo". Also `string f<T>() => nameof(T)` will return "T". There are pros and cons to this decision. In its favor, it keeps the rules of nameof very simple and predictable. In the case of nameof(member), it would be a hindrance in most (not all) bread-and-butter cases to give a fully qualified member name. Also it's convention that "System.Type.Name" refers to an unqualified name. Therefore also nameof(type) should be unqualified. If ever you want a fully-qualified type name you can use typeof(). If you want to use nameof on a type but also get generic type parameters or arguments then you can construct them yourself, e.g. nameof(List<int>) + "`2". Also the languages have no current notion of metadata name, and metadata name can change with obfuscation.
+6. __Use source names or metadata names? Source.__ Settled on source names, based on the evidence... v1/v2/v3 were source names because that's how we started; then we heard feedback that people were interested in metadata names and v4 explored metadata names. But I think the experiment was a failure: it ended up looking like _disallowing_ nameof on types was better than picking metadata names. At LDM, after heated debate, we settled on source names. For instance `using foo=X.Y.Z; nameof(foo)` will return "foo". Also `string f<T>() => nameof(T)` will return "T". There are pros and cons to this decision. In its favor, it keeps the rules of nameof very simple and predictable. In the case of nameof(member), it would be a hindrance in most (not all) bread-and-butter cases to give a fully qualified member name. Also it's convention that "System.Type.Name" refers to an unqualified name. Therefore also nameof(type) should be unqualified. If ever you want a fully-qualified type name you can use typeof(). If you want to use nameof on a type but also get generic type parameters or arguments then you can construct them yourself, e.g. nameof(List\<int>) + "`2". Also the languages have no current notion of metadata name, and metadata name can change with obfuscation.
 7. __Allow arbitrary expressions or just a subset?__ We want to try out the proposal "just a subset" because we're uneasy with full expressions. That's what v5 does. We haven't previously explored this avenue, and it deserves a try.
 8. __Allow generic type arguments?__ Presumably 'yes' when naming a type since that's how expression binding already works. And presumably 'no' when naming a method-group since type arguments are used/inferred during overload resolution, and it would be confusing to also have to deal with that in nameof. [this item 8 was added after the initial v5 spec]
 

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

@@ -346,7 +346,7 @@ Array slices represent an interesting design dilemma between performance and usa
 
 Of course this would require quite a change to the runtime. The performance consequences of that could be negative even on the existing kind of arrays. As importantly, slices themselves would be more efficiently represented by a struct type, and for high-perf scenarios, having to allocate a heap object for them might be prohibitive.
 
-One intermediate approach might be to have slices be a struct type Slice<T>, but to let it implicitly convert to T[] in such a way that the underlying storage is still shared. That way you can use Slice<T> for high performance slice manipulation (e.g. in recursive algorithms where you keep subdividing), but still make use of existing array-based APIs at the cost of a boxing-like conversion allocating a small object.
+One intermediate approach might be to have slices be a struct type Slice\<T>, but to let it implicitly convert to T[] in such a way that the underlying storage is still shared. That way you can use Slice\<T> for high performance slice manipulation (e.g. in recursive algorithms where you keep subdividing), but still make use of existing array-based APIs at the cost of a boxing-like conversion allocating a small object.
 
 ref locals and ref returns
 --------------------------

meetings/2015/LDM-2015-03-25-Design-Review.md

@@ -116,7 +116,7 @@ The scenario is good, not the current proposal.
 
 There's agreement on wanting the feature and on the syntax (#347, #1207).
 
-We probably prefer a value type version of Tuple<T>. Of course those would be subject to tearing, like all structs. We're willing to be swayed.
+We probably prefer a value type version of Tuple\<T>. Of course those would be subject to tearing, like all structs. We're willing to be swayed.
 
 There are performance trade offs around allocation vs copying, and also around generic instantiation. We could do some experiments in F# source code, which already has tuples.
 

meetings/2015/LDM-2015-03-25-Notes.md

@@ -160,10 +160,10 @@ We think we want an expression form too (no proposed syntax yet, but for inspira
 - Which types have syntactic support?
 	- Primitives and string
 	- Records
-	- Nullable<T>
+	- Nullable\<T>
 	- objects with properties
 	- anonymous types?
 	- arrays?
 	- List? Dictionary?
 	- Tuple<...>?
-	- IEnumerable<T>?
+	- IEnumerable\<T>?

meetings/2015/LDM-2015-07-07.md

@@ -4,7 +4,7 @@ Discussion for these notes can be found at https://github.com/dotnet/roslyn/issu
 
 Quotes of the day:
 
-> "I don't think I've had a Quote of the Day for years <sigh>" 
+> "I don't think I've had a Quote of the Day for years \<sigh>" 
 > "What you just described is awful, so we can't go there!"
 
 ## Agenda

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

@@ -9,7 +9,7 @@
 # Abstracting over memory spans
 
 
-It's common for teams building IO/data pipelines to invent a type similar to Span<T>, which is intended to abstract over native and managed memory, so that you write code over them only ones.
+It's common for teams building IO/data pipelines to invent a type similar to Span\<T>, which is intended to abstract over native and managed memory, so that you write code over them only ones.
 
 * Native memory
 * Managed arrays
@@ -45,7 +45,7 @@ These need to be treated as "ref-like":
 * Can't be a type argument
 * Etc...
 
-Also need a ReadOnlySpan<T> or similar.
+Also need a ReadOnlySpan\<T> or similar.
 
 So need a way to specify ref-like types, so that the compiler wants to enforce it.
 
@@ -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 rarely 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.
 
@@ -135,10 +135,10 @@ Structs that can't be passed by value
 TO avoid copying costs, semantic errors etc. Icing.
 
 
-FOr Memory<T>
+FOr Memory\<T>
 -------------
 
-Not ready to discuss yet, but is there a way that you can prevent a Memory<T> from getting freed while a Span is "out".
+Not ready to discuss yet, but is there a way that you can prevent a Memory\<T> from getting freed while a Span is "out".
 
 Maybe some version of "fixed" can help. A challenge to generalize this from Span to any ref-like type.
 

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

@@ -75,7 +75,7 @@ Options:
 - more general: single-method interfaces, anonymous classes...
 
 Can't make IAsyncEnumerable a delegate type,because we want to implement it on specific classes.
-Could we make IAsyncEnumerator a delegate? Would need to reduce to one method. But that can't both be covariant and return a Task<bool>.
+Could we make IAsyncEnumerator a delegate? Would need to reduce to one method. But that can't both be covariant and return a Task\<bool>.
 
 Iterators may not be the *most* highly used feature, and it may be ok if this is a bit woolly. But it's *super* useful when you need it.
 

meetings/2018/LDM-2018-03-19.md

@@ -46,7 +46,7 @@ Punt to 8.x, when we know more of the rest of the pattern story.
 
 We've talked about this many times in the past, but couldn't settle on a syntax that was nice enough and worth its while.
 
-A 4th option: allow M<string>(...) to match an M with more type parameters. But that probably goes against intuition and would complicate overload resolution.
+A 4th option: allow M\<string>(...) to match an M with more type parameters. But that probably goes against intuition and would complicate overload resolution.
 
 For 2: Just commas is known from typeof, so that concept is already in the language, though you can't mix "there" and "not there" today.
 

meetings/2018/LDM-2018-08-20.md

@@ -10,7 +10,7 @@ Nullable open issues:
 4. Expanding the feature
 5. Is T? where T : class? allowed or meaningful?
 6. Typing judgments containing oblivious types
-7. Unconstrained T in List<T> then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`?
+7. Unconstrained T in List\<T> then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`?
 
 # Discussion
 

meetings/2018/LDM-2018-12-03.md

@@ -81,8 +81,8 @@ Proposals:
 1. Add indexers that return the same types (string returns a string, array returns
    an array, Span returns a Span, etc.)
 2. Don't add indexers that allocate/copy, add overloads to do slicing with ranges
-3. Add indexers that return Span<T>
-4. Add indexers that return Memory<T>
+3. Add indexers that return Span\<T>
+4. Add indexers that return Memory\<T>
 5. Do nothing
 
 (3) and (2) are initially attractive because they automatically produce the

meetings/2018/README.md

@@ -93,7 +93,7 @@ We continued to discuss the range operator in C# and the underlying types for it
 4. Expanding the feature
 5. Is T? where T : class? allowed or meaningful?
 6. Typing judgments containing oblivious types
-7. Unconstrained T in List<T> then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`?
+7. Unconstrained T in List\<T> then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`?
 
 ## August 22, 2018
 

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

@@ -55,7 +55,7 @@ resolving the ambiguity.
 1. Keep the order, but address using lookahead
 2. ? is a type constructor (reverse the order of brackets and question marks)
 3. reverse the order of ?'s only
-4. Introduce Array<T>
+4. Introduce Array\<T>
 ```C#
 Array<int[]?>
 new Array<int[]?>(3)

meetings/2019/LDM-2019-04-03.md

@@ -24,7 +24,7 @@ class C : I
 ```
 
 This was valid code in C# 7 and would always match the Nullable
-overload because T? could only mean Nullable<T>. Now, however, `T?`
+overload because T? could only mean Nullable\<T>. Now, however, `T?`
 is ambiguous. The ambiguity also cannot be fixed because we do not
 allow you to write the constraints.
 

proposals/csharp-7.2/span-safety.md

@@ -13,7 +13,7 @@ All the above problems would be alleviated if instances of `Span<T>` are constra
 
 An additional problem arises due to composition. It would be generally desirable to build more complex data types that would embed `Span<T>` and `ReadOnlySpan<T>` instances. Such composite types would have to be structs and would share all the hazards and requirements of `Span<T>`. As a result the safety rules described here should be viewed as applicable to the whole range of **_ref-like types_**.
 
-The <a href="#draft-language-specification">draft language specification</a> is intended to ensure that values of a ref-like type occurs only on the stack.
+The [draft language specification](#draft-language-specification) is intended to ensure that values of a ref-like type occurs only on the stack.
 
 ## Generalized `ref-like` types in source code
 
@@ -129,7 +129,7 @@ ref SpanLikeType Test2(ref SpanLikeType param1, Span<byte> param2)
 
 ----------------
 
-## <a name="draft-language-specification"></a>Draft language specification
+## Draft language specification
 
 Below we describe a set of safety rules for ref-like types (`ref struct`s) to ensure that values of these types occur only on the stack. A different, simpler set of safety rules would be possible if locals cannot be passed by reference. This specification would also permit the safe reassignment of ref locals.
 
@@ -292,7 +292,7 @@ We wish to ensure that no `ref` local variable, and no variable of `ref struct`
 
 ## Future Considerations
 
-### Length one Span<T> over ref values
+### Length one Span\<T> over ref values
 Though not legal today there are cases where creating a length one `Span<T>` instance over a value would be beneficial:
 
 ```csharp