<i>To make the text easy to read and allow for indentation that developers like in code, these string literals will naturally remove the indentation specified on the last line when producing the final literal value.</i><p>This is the same rule that Oil has; I think it came from the Julia language (or at least that's where I got it from)<p><i>Oil Has Multi-line Commands and String Literals</i> <a href="http://www.oilshell.org/blog/2021/09/multiline.html" rel="nofollow">http://www.oilshell.org/blog/2021/09/multiline.html</a>
I've given some thought to this kind of string literal in the past (for my imaginary programming language). I want a syntax <i>something</i> like this:<p><pre><code> var xml = """<element attr="content">
""" <body>
""" </body>
"""</element>
""";
</code></pre>
This would give you the string:<p><pre><code> <element attr="content">
<body>
</body>
</element>(no newline)
</code></pre>
If you wanted a newline at the end, you'd do this:<p><pre><code> var xml = """<element attr="content">
""" <body>
""" </body>
"""</element>
"""
""";
</code></pre>
Basically the end delimiter of the string would be the last """. You could concatenate two strings like so:<p><pre><code> var xml = """<element attr="content">
""" <body>
""" </body>
"""</element>
"""
""" // this string ended on this line
+
"""<element attr="content">
""" <body>
""" </body>
"""</element>
"""
"""; // this string ended on this line
</code></pre>
This could use the same logic for using <i>at least</i> three quotes as the indicator that it's a multiline string.<p>Please, tear this apart and offer improvements.<p>Edit: this is conceptually similar to Zig's multiline literal: <a href="https://ziglang.org/documentation/master/#Multiline-String-Literals" rel="nofollow">https://ziglang.org/documentation/master/#Multiline-String-L...</a>
I have been temporarily working with c# for the past month after years of Go. It’s a different philosophy to Go, there is a lot of syntactic sugar and magic spells that make your life easy… but I don’t know if I prefer that to the Go way of doing things. I was pleasantly surprised tho. Much better experience than working with Java
I got confused at the first example.<p><pre><code> var xml = """
<element attr="content">
<body>
</body>
</element>
""";
</code></pre>
And then they say that xml gets this...<p><pre><code> <element attr="content">
<body>
</body>
</element>
</code></pre>
But they <i>don't</i> explicitly say if the new lines after and before the """ 's are considered part of the literal string or not.<p>Are they?
I've used this in other languages and I don't like it. It's the wrong approach to solving the problem. As soon as I want to embed some multi-line string in my code then I'd be better of just having it in it's own file.<p>.NET does allow you embed files directly into your project and read in those files but it's a lot of confusing boilerplate.<p>If .NET provided a really easy way to take a file from the project and create a compile-time string from it then I think that would be significantly more useful than this proposal.
Perl's heredoc is better. You get to pick the delimiter. <a href="https://perlmaven.com/here-documents" rel="nofollow">https://perlmaven.com/here-documents</a>
... Why?<p>There are so many different ways to do strings in C#. Adding features like this just makes the language harder to learn, and the compiler harder to implement.<p>At this point, it's probably better to adjust the compiler to make it easier to turn a text file into a hardcoded string. The embedded resource approach works, but it could be significantly smoother.<p>Or, maybe the compiler needs some form of a plugin architecture so people who want obscure features can figure out how to add them?
<p><pre><code> var v = """"""
contents"""""
""""""
</code></pre>
lol.<p>I like the proposal to have these sort of raw strings, where indentations are removed, but can't they use a symbol before the string like they do with interpolation `$` or literals `@`?<p>I know it says design decision to go with 1 more " than the longest sequence of " in the string, but why ?
Nice, I'm surprized this is not already in the language. The only thing I find a bit strange is that the delimiters must be on separate lines (unless it is the special one-line-form). So this is apparantly not legal:<p><pre><code> var s = """This is a
multiline string""";
</code></pre>
Requiring the start and especially end quotes to be on a separate line makes it take a lot of vertical space. But OTOH, that is consistent with the default coding style in C# which is vertically verbose (with {} on lines by themselves).
A little while ago, I discovered that...<p><pre><code> $"A{new List<string>{$"B{"{C}"}D"}.First()}E"
</code></pre>
... was valid C#.<p>This means that a C# compiler can't start with a simple tokenizing loop. That compiler phase would have to keep track of state in a stack, recording what each } character means while its still looping through code character-by-character.<p>Now we're adding {{ and }} into the equation. Yay.
I hope it will also normalize newlines to `\n`. The current version of raw literals (@"...") just puts there whatever is in the file, so it in practice depends on if your program was compiled on Windows or Linux. Surely that should be irrelevant for the compilation to intermediate language
This is fantastic! After this is in, can anyone propose a better documentation syntax please? I am really tired of typing verbose XML as comments, and not even being able to write "a < b" or "T<int>" in my comments...
Interpolation is its own can of worms, but if you just want to be able to encode absolutely anything without escape characters, you just need two delimiters:<p><pre><code> "*n [stringA] "*n
"*n [stringB] '*n
'*n [stringC] "*n
'*n [stringD] '*n
</code></pre>
Each string may contain runs of contiguous single or double quotes of length less than n, and furthermore:<p>stringA may start and/or end with a single quote<p>stringB may start with a single quote and/or end with a double quote<p>stringC may start with a double quote and/or end with a single quote<p>stringD may start and/or end with a double quote
For the single-line case, what happens for:<p><pre><code> """""""
""""""""
</code></pre>
Are those strings containing `"` and `""` or are they empty strings? Is the first case an error because the starting and ending quote counts do not match? If the number of quote chars is even, do the contents alternate between `"` and empty as the number of surrounding quotes increases?
I would much rather see something like this:<p><pre><code> string longString =
`This
` allows
` differentiation
` of
`formatting
` indention
` from
` leading
` string
` spaces
` using
` back-ticks (\`)</code></pre>
In place of all of the special rules for handling indentation, I wonder if they could simply define some extra starting chars (besides $$""" for controlling interpolation) to indicate suppress-leading-newline or suppress-ending-newline etc. Offhand this would seem more explicit than implicit, and be searchable (unlike a pattern).<p>Other than that, ++ for any mechanism to quote to arbitrary depth. I have imagined<p>[abcfoo[ ...anything but ]abcfoo]... ]abcfoo]<p>as another approach.
I like the three-quote literal syntax in general, and am a bit surprised that C# doesn't have this already. Even Java has had this for awhile now!<p>But I don't like the indented form, where nested triple-quotes are ignored. Whitespace formatting is fine when I'm working with Python, but I really don't want to mix that paradigm when I'm working with curly-brace languages.
> This allows code to look natural, while still producing literals that are desired, and avoiding runtime costs if this required the use of specialized string manipulation routines.<p>Maybe a source generator would be applicable here? Not as nice has having it built into the language of course, but it would at least eliminate these runtime costs.
With all the hacks and exploits going on, and (Log4J) more security awareness coming,<p>I've been considering a safe String class that prevents some characters like CR,LF,\ that are seldom needed in business strings but used in system level things. Drawing a line between these two would increase security.
I always found these complex indentation-stripping rules to be confusing in a language such as Python. I was under the impression that C# doesn't treat whitespace significantly, so why do they need all these complex rules? Just interpret what's between the quotes literally.
I've long wanted a more succinct way of writing implicitly typed arrays. Whenever you work with data directly in the code, for example when hacking on leetcode, you end you with lots of horrible nested arrays:<p>new [] {new [] {1, 2}, new [] {3, 4}};<p>Something like:<p>@[ @[1, 2], @[3, 4] ]
The issue is being discussed here: <a href="https://github.com/dotnet/csharplang/issues/4304" rel="nofollow">https://github.com/dotnet/csharplang/issues/4304</a>
I guess a good thing about proposals like this is as an early warning system.<p>When a language gets its fourth or fifth string literal syntax, its process is probably broken.