maxmustermann/csharplang
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Typo and rendering fixes (#4761)

Browse source
This commit is contained in:
Joseph Musser 2021-05-18 19:27:15 -04:00 committed by GitHub
parent f817e1f3db
commit f751454623
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
meetings/2021/LDM-2021-05-17.md
View file

@ -23,7 +23,7 @@ https://github.com/dotnet/csharplang/issues/4304
Today we took a look through the proposal for raw string literals. This would add a new type of string literal to C#, specifically
for working with embedded language scenarios that are difficult to work with in C# today. A number of other languages have added
similar features, though our colleagues on Java are perhaps the most direct inspiration for this proposal (particularly with the
whitespace triming feature).
whitespace trimming feature).
Overall, the LDM is universally in favor of the feature. Some details still remain to be worked out, but we believe this is a feature
that will benefit C#, despite the complexity in adding yet another string literal format.
@ -47,7 +47,7 @@ in the file which breaks up the flow of the file and can make subsequent indenta
whitespace from the start of every line, determined by the whitespace preceding the final quotes. This feature has a couple of levers
we can tune to increase or decrease the requirements on the user, namely around handling blank lines. The proposal currently says
that blank lines must have a _prefix_ of the removed whitespace on the line. That means that, if the whitespace to be removed is
`<tab> <tab> <space>`, a blank line with `` is fine, as is a blank line with `<tab> <tab>`. Both are prefixes of the whitespace to
`<tab> <tab> <space>`, a completely empty line is fine, as is a blank line with `<tab> <tab>`. Both are prefixes of the whitespace to
be removed. However, a line with `<tab> <space>` is _not_ fine, because that is not a prefix of the whitespace to be removed. We
could make this more strict by saying that a blank line must either have the full whitespace to be removed, or no content at all.
While this is more strict, it could end up being a better user experience: whitespace is, by nature, hard to visualize, and providing
@ -62,7 +62,7 @@ We can relax this later if it makes the experience better.
### Language fences
We also looked at allowing a language fence in literals, similar to how markdown works. In multiline markdown strings, \`\`\`identifier
We also looked at allowing a language fence in literals, similar to how markdown works. In multiline markdown strings, ```` ```identifier ````
marks the code block as having a specific language, which the markdown renderer can use to render the text inline. In C# string literals
today, there's fragmented support for this implemented in a number of tools: VS, for example, detects when a string is being passed
directly to a regex API, and also has support for a comment syntax to turn on highlighting for different locations. We could standardize
@ -78,7 +78,7 @@ We're mixed on language fences, leaning against supporting them for now. More de
### Interpolation
This proposal didn't originally have interpolation, but after a large pushback from the community interpolation was added. Because the
This proposal didn't originally have interpolation, but after a large pushback from the community, interpolation was added. Because the
goal of the proposal is to represent all strings without escaping, the immediate next question is how we represent interpolation holes
without requiring escaping of braces. The proposal suggests we use the number of `$`s in front of the raw string to represent the number
of braces required to trigger an interpolation hole: `$$"""{}"""` would be the string `{}`, because `{{}}` is needed to be counted as an