From 6cd82c21edbaa235416155e8d6b867bc850db830 Mon Sep 17 00:00:00 2001 From: Nick Schonning Date: Sat, 25 May 2019 01:31:46 -0400 Subject: [PATCH] fix: MD033/no-inline-html Inline HTML get swallowed in MD and HTML rendering --- meetings/2013/LDM-2013-10-21.md | 4 ++-- meetings/2013/LDM-2013-11-04.md | 8 ++++---- meetings/2014/LDM-2014-10-01.md | 2 +- meetings/2014/LDM-2014-10-15.md | 2 +- meetings/2015/LDM-2015-01-21.md | 2 +- meetings/2015/LDM-2015-03-25-Design-Review.md | 2 +- meetings/2015/LDM-2015-03-25-Notes.md | 4 ++-- meetings/2015/LDM-2015-07-07.md | 2 +- meetings/2016/LDM-2016-11-01.md | 10 +++++----- meetings/2017/LDM-2017-01-18.md | 2 +- meetings/2018/LDM-2018-03-19.md | 2 +- meetings/2018/LDM-2018-08-20.md | 2 +- meetings/2018/LDM-2018-12-03.md | 4 ++-- meetings/2018/README.md | 2 +- meetings/2019/LDM-2019-01-09.md | 2 +- meetings/2019/LDM-2019-04-03.md | 2 +- proposals/csharp-7.2/span-safety.md | 6 +++--- 17 files changed, 29 insertions(+), 29 deletions(-) diff --git a/meetings/2013/LDM-2013-10-21.md b/meetings/2013/LDM-2013-10-21.md index c34e2c8..ca6a5cf 100644 --- a/meetings/2013/LDM-2013-10-21.md +++ b/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 -2. Lightweight Dynamic +1. Primary Constructors \ +2. Lightweight Dynamic \ ## Primary Constructors diff --git a/meetings/2013/LDM-2013-11-04.md b/meetings/2013/LDM-2013-11-04.md index bcd7e56..47c3064 100644 --- a/meetings/2013/LDM-2013-11-04.md +++ b/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
-2. Expression-bodied function members
-3. Lightweight dynamic +1. Initialized and getter-only auto-properties \
+2. Expression-bodied function members \
+3. Lightweight dynamic \ ## 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.Foo for some value of . +We like the “dot-like” syntax approach to LW dynamic member access, and we think it should be of the form x.\Foo for some value of \. diff --git a/meetings/2014/LDM-2014-10-01.md b/meetings/2014/LDM-2014-10-01.md index bcdd833..3ad58e3 100644 --- a/meetings/2014/LDM-2014-10-01.md +++ b/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 is able to initialize static readonly fields in specializations of G e.g. `G.x=15;`. The CLR does indeed maintain separate storage locations for each static readonly fields, so `G.g` and `G.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\ is able to initialize static readonly fields in specializations of G e.g. `G.x=15;`. The CLR does indeed maintain separate storage locations for each static readonly fields, so `G.g` and `G.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_. diff --git a/meetings/2014/LDM-2014-10-15.md b/meetings/2014/LDM-2014-10-15.md index ef1a87e..86e5fc7 100644 --- a/meetings/2014/LDM-2014-10-15.md +++ b/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() => 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) + "`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() => 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\) + "`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] diff --git a/meetings/2015/LDM-2015-01-21.md b/meetings/2015/LDM-2015-01-21.md index 8b28244..be51908 100644 --- a/meetings/2015/LDM-2015-01-21.md +++ b/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, 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 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\, 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\ 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 -------------------------- diff --git a/meetings/2015/LDM-2015-03-25-Design-Review.md b/meetings/2015/LDM-2015-03-25-Design-Review.md index 513daab..86d5380 100644 --- a/meetings/2015/LDM-2015-03-25-Design-Review.md +++ b/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. 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\. 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. diff --git a/meetings/2015/LDM-2015-03-25-Notes.md b/meetings/2015/LDM-2015-03-25-Notes.md index 97547db..f6149f4 100644 --- a/meetings/2015/LDM-2015-03-25-Notes.md +++ b/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 + - Nullable\ - objects with properties - anonymous types? - arrays? - List? Dictionary? - Tuple<...>? - - IEnumerable? + - IEnumerable\? diff --git a/meetings/2015/LDM-2015-07-07.md b/meetings/2015/LDM-2015-07-07.md index b8a74a4..ccaffb6 100644 --- a/meetings/2015/LDM-2015-07-07.md +++ b/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 " +> "I don't think I've had a Quote of the Day for years \" > "What you just described is awful, so we can't go there!" ## Agenda diff --git a/meetings/2016/LDM-2016-11-01.md b/meetings/2016/LDM-2016-11-01.md index 09dae66..5556ec5 100644 --- a/meetings/2016/LDM-2016-11-01.md +++ b/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, 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\, 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 or similar. +Also need a ReadOnlySpan\ 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 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\ 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 +FOr Memory\ ------------- -Not ready to discuss yet, but is there a way that you can prevent a Memory from getting freed while a Span is "out". +Not ready to discuss yet, but is there a way that you can prevent a Memory\ 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. diff --git a/meetings/2017/LDM-2017-01-18.md b/meetings/2017/LDM-2017-01-18.md index 1173498..240e386 100644 --- a/meetings/2017/LDM-2017-01-18.md +++ b/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. +Could we make IAsyncEnumerator a delegate? Would need to reduce to one method. But that can't both be covariant and return a Task\. 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. diff --git a/meetings/2018/LDM-2018-03-19.md b/meetings/2018/LDM-2018-03-19.md index f3aadba..2e57ce3 100644 --- a/meetings/2018/LDM-2018-03-19.md +++ b/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(...) to match an M with more type parameters. But that probably goes against intuition and would complicate overload resolution. +A 4th option: allow M\(...) 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. diff --git a/meetings/2018/LDM-2018-08-20.md b/meetings/2018/LDM-2018-08-20.md index c2c997b..ed811fa 100644 --- a/meetings/2018/LDM-2018-08-20.md +++ b/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 then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`? +7. Unconstrained T in List\ then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`? # Discussion diff --git a/meetings/2018/LDM-2018-12-03.md b/meetings/2018/LDM-2018-12-03.md index ea034cd..1db798f 100644 --- a/meetings/2018/LDM-2018-12-03.md +++ b/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 -4. Add indexers that return Memory +3. Add indexers that return Span\ +4. Add indexers that return Memory\ 5. Do nothing (3) and (2) are initially attractive because they automatically produce the diff --git a/meetings/2018/README.md b/meetings/2018/README.md index e77a174..91a625d 100644 --- a/meetings/2018/README.md +++ b/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 then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`? +7. Unconstrained T in List\ then `FirstOrDefault()`. What attribute to annotate `FirstOrDefault`? ## August 22, 2018 diff --git a/meetings/2019/LDM-2019-01-09.md b/meetings/2019/LDM-2019-01-09.md index 978a354..49a3e2b 100644 --- a/meetings/2019/LDM-2019-01-09.md +++ b/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 +4. Introduce Array\ ```C# Array new Array(3) diff --git a/meetings/2019/LDM-2019-04-03.md b/meetings/2019/LDM-2019-04-03.md index 9fae6da..5931551 100644 --- a/meetings/2019/LDM-2019-04-03.md +++ b/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. Now, however, `T?` +overload because T? could only mean Nullable\. Now, however, `T?` is ambiguous. The ambiguity also cannot be fixed because we do not allow you to write the constraints. diff --git a/proposals/csharp-7.2/span-safety.md b/proposals/csharp-7.2/span-safety.md index 8752058..d5f5607 100644 --- a/proposals/csharp-7.2/span-safety.md +++ b/proposals/csharp-7.2/span-safety.md @@ -13,7 +13,7 @@ All the above problems would be alleviated if instances of `Span` are constra An additional problem arises due to composition. It would be generally desirable to build more complex data types that would embed `Span` and `ReadOnlySpan` instances. Such composite types would have to be structs and would share all the hazards and requirements of `Span`. As a result the safety rules described here should be viewed as applicable to the whole range of **_ref-like types_**. -The draft language specification 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 param2) ---------------- -## 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 over ref values +### Length one Span\ over ref values Though not legal today there are cases where creating a length one `Span` instance over a value would be beneficial: ```csharp