[Proposal]: Raw string literal #8646

CyrusNajmabadi · 2021-01-06T06:17:20Z

CyrusNajmabadi
Jan 6, 2021
Collaborator

Raw string literal

Proposed
Prototype: No prototype needed.
Implementation: In: https://github.com/dotnet/roslyn/tree/features/RawStringLiterals
Specification: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/raw-string-literal.md

Summary

Allow a new form of string literal that starts with a minimum of three """ characters (but no maximum), optionally followed by a new_line, the content of the string, and then ends with the same number of quotes that the literal started with. For example:

var xml = """
          <element attr="content"/>
          """;

Spec: https://github.com/dotnet/csharplang/blob/main/proposals/raw-string-literal.md

Special thanks to @jnm2 for a deep review of this proposal

AartBluestoke · 2021-01-06T06:51:04Z

AartBluestoke
Jan 6, 2021

is there a way that literal be combined with $ to embed tokens, or is this completely literal strings only?

string exampleJson= $"""
                     {{
                         "name" = "{this.thingName}"
                     }}""";

(expecting that the answer is 'no - raw means raw with no interpolation' )

0 replies

CyrusNajmabadi · 2021-01-06T06:58:48Z

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

is there a way that literal be combined with $ to embed tokens, or is this completely literal strings only?

I personally think our existing strings are good enough for the template literal case. This is only for raw strings, and is intended when you just want to take a real snippet of some other language out there and put it into C#.

The moment we allow things like { to mean something, then we run into the escaping problem again. You'll have the problem that doing this, along with json, will be just as painful as the past.

So, tbh, i believe this should just be for raw-strings. And the best way to handle that is to make sure that you can provide a literal that will never conflict with the contents, and that the contents can't ever have meaning. :)

0 replies

Tragen · 2021-01-06T09:06:54Z

Tragen
Jan 6, 2021

In my opinion, Example 2 should trow an error and is confusing.
The ending string literal must be in its own line.
So the string doesn't end with a new line as also it doesn't start with one.
If you want an empty line at the end, add an empty line.
Perhaps this makes it also easier for the parser.

0 replies

AartBluestoke · 2021-01-06T09:23:15Z

AartBluestoke
Jan 6, 2021

"Perhaps this makes it also easier for the parser."
@Tragen agreed, that would also allow strings of quotes to appear mid-string, however how would you indicate if the block of text ends in a new line or not?

0 replies

Tragen · 2021-01-06T09:36:57Z

Tragen
Jan 6, 2021

Thats easy. Add an empty line

No empty line at the end. Last character in the string is >

var xml = """
          <element attr="contents">
            <body>
            </body>
          </element>
          """;

with empty line at the end

var xml = """
          <element attr="contents">
            <body>
            </body>
          </element>

          """;

For me, that is much more intuitive and logical

0 replies

merarischroeder · 2021-01-06T12:10:32Z

merarischroeder
Jan 6, 2021

is there a way that literal be combined with $ to embed tokens, or is this completely literal strings only?

I personally think our existing strings are good enough for the template literal case. This is only for raw strings, and is intended when you just want to take a real snippet of some other language out there and put it into C#.

The moment we allow things like { to mean something, then we run into the escaping problem again. You'll have the problem that doing this, along with json, will be just as painful as the past.

So, tbh, i believe this should just be for raw-strings. And the best way to handle that is to make sure that you can provide a literal that will never conflict with the contents, and that the contents can't ever have meaning. :)

Actually, I believe the escalating problem is about double-quote marks specifically. Having a raw-string+interpolation should therefore be possible and useful for at least HTML,XML and non-C markup/languages, but this is something that can be deferred for the future.

Examples:

example[0] = $"""<a href="{url}">{label}</a>"""
example[1] = $"""<tiger age="{age}"><eyes colour="{eye_color}" count="2"></tiger>"""

(I am using a single-line mode for these examples for brevity)

Examples with raw strings that would have braces:

var templateName = "C# Example Generator";
$"""
void Example(string Name)
{{
    Console.WriteLine($"Hello {{Name}}, Welcome to {templateName}");
}}
"""

Although the braces still need escaping, the ability to include raw double-quotes makes this much easier to read.

0 replies

merarischroeder · 2021-01-06T12:16:38Z

merarischroeder
Jan 6, 2021

is there a way that literal be combined with $ to embed tokens, or is this completely literal strings only?

I personally think our existing strings are good enough for the template literal case. This is only for raw strings, and is intended when you just want to take a real snippet of some other language out there and put it into C#.

The moment we allow things like { to mean something, then we run into the escaping problem again. You'll have the problem that doing this, along with json, will be just as painful as the past.

So, tbh, i believe this should just be for raw-strings. And the best way to handle that is to make sure that you can provide a literal that will never conflict with the contents, and that the contents can't ever have meaning. :)

I don't see any conceptual paradox in having single-line and multi-line raw string literals with de-indentation.

example[0] = """raw string here"""; //closing quote is found on the same-line, so there is no multi-line processing to do
example[1] = """multiline string here
                with no de-indentation, because 
                the string opener was not followed by new-line""";
example[2] = """
                this string can be de-indented
                because the string opener
                was directly followed by new-line"""; //it shouldn't matter if the string closer is here, or on the following line, the first line's indentation is the reference-point.
example[3] = """
                this also means, that indentation
                       can increase above the base-line
                       the same amount of spaces are 
                       still removed according to the base-line
"""; //even if the string closer has zero indent

Perhaps it isn't impossible to implement, but it would be much more complex or the spec-system isn't flexible enough?

0 replies

HaloFour · 2021-01-06T13:23:19Z

HaloFour
Jan 6, 2021

@Tragen

In my opinion, Example 2 should trow an error and is confusing.
The ending string literal must be in its own line.
So the string doesn't end with a new line as also it doesn't start with one.
If you want an empty line at the end, add an empty line.
Perhaps this makes it also easier for the parser.

I disagree. There's nothing confusing about the closing quote being on the same line. It's exactly how text blocks work in Python and Java and it is not a problem in either of those languages.

0 replies

Tragen · 2021-01-06T13:26:30Z

Tragen
Jan 6, 2021

@HaloFour
A lot of other languages disagree with you.
When you can have it on the same line, then you would have an empty line at the beginning in all of the examples in the first post.

0 replies

HaloFour · 2021-01-06T13:42:45Z

HaloFour
Jan 6, 2021

@Tragen

Other languages are welcome to do what they wish, but given two major languages have adopted the behavior proposed above it demonstrates that there is nothing inherently confusing about it.

0 replies

Tragen · 2021-01-06T14:09:19Z

Tragen
Jan 6, 2021

Because major languages have some features doesn't automatically mean that it isn't confusing.
E.g. C++ is very confusing.

0 replies

HaloFour · 2021-01-06T15:48:13Z

HaloFour
Jan 6, 2021

@Tragen

Many different ways to skin that cat. To be honest I kind of prefer C++'s general approach to raw strings over text blocks since you're given a lot of flexibility to customize the delimiters while still retaining the syntax of a string (unlike heredocs in many languages). See the syntax I originally proposed here: #89

I will admit that having the closing delimiter on a separate line does make it easier to control the indentation without including that final newline character, and Cyrus was a little surprised that Java does include that newline when the delimiter is on the next line (so does Python).

0 replies

CyrusNajmabadi · 2021-01-06T16:02:39Z

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

Because major languages have some features doesn't automatically mean that it isn't confusing.

It does help with the argument though. Ultimately, either approach will need to be learned. Given that this doesn't really seem to have been a problem for many other languages, I'm not too worried for us. That said, I'm certain we'll discuss that option when we design this.

0 replies

CyrusNajmabadi · 2021-01-06T16:03:24Z

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

For me, that is much more intuitive and logical

I'm certain we'll discuss this during the design process.

0 replies

CyrusNajmabadi · 2021-01-06T16:04:06Z

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

I don't see any conceptual paradox in having single-line and multi-line raw string literals with de-indentation.

I'm certain we'll discuss this during the design process.

0 replies

KieranDevvs · 2023-01-13T10:43:12Z

KieranDevvs
Jan 13, 2023

Why not use AI in the future to guess what I am trying to do instead of trying to come up with new syntax to do it right

Because there would be no defined behavior and it would differ between each user environment.

0 replies

jrmoreno1 · 2023-06-10T18:18:54Z

jrmoreno1
Jun 10, 2023

Is there a way to make this work when compiling a framework application (i.e. not 11) but using 17.0+?

This is an EXTREMELY useful feature, and it's a real shame if it can't be used with older projects since it is really only the compiler that needs to know about it.

0 replies

CyrusNajmabadi · 2023-06-10T18:30:10Z

CyrusNajmabadi
Jun 10, 2023
Collaborator Author

@jrmoreno1 not sure wha you mean. There are no restrictions on using this feature.

0 replies

jrmoreno1 · 2023-06-10T18:36:54Z

jrmoreno1
Jun 10, 2023

@CyrusNajmabadi : I am using the latest version of VS (17.6.2), with a console application targeting net48 (which will automatically target language version 7.3), results in CS8730.

But since this is entirely compiler magic and both my build server and any local builds will be with a compiler that supports this feature, it would be terrific if it worked.

It's very annoying to start typing and then get an error message telling me that I have to do a lot of escaping to get things to work...

0 replies

CyrusNajmabadi · 2023-06-10T19:35:52Z

CyrusNajmabadi
Jun 10, 2023
Collaborator Author

You can manually set the language version. This is a requirement. If you have your lang version set to something lower (implicitly or explicitly) it will of course be blocked as that's literally what a language version is (a claim about which versions of the language you desire to use).

Use the <LangVersion> tag for this.

0 replies

HaloFour · 2023-06-10T22:14:14Z

HaloFour
Jun 10, 2023

@CyrusNajmabadi

This is technically not a supported scenario, though, right? I thought language versions were now tied to runtime versions, regardless of whether or not runtime changes were required to support any specific features, in order to avoid confusion as to which combination of features would work.

0 replies

CyrusNajmabadi · 2023-06-10T23:15:17Z

CyrusNajmabadi
Jun 10, 2023
Collaborator Author

it's not supported. but it's something that can be done. We're not going to stop you. We're not going to spend any effort on going and making these scenarios supported though.

0 replies

KyleMit · 2024-11-13T16:59:12Z

KyleMit
Nov 13, 2024

Should this be closed now that the proposal has gone through?

0 replies

CyrusNajmabadi · 2024-11-13T17:15:50Z

CyrusNajmabadi
Nov 13, 2024
Collaborator Author

@KyleMit We have not added this to the ecma standard yet.

0 replies

CyrusNajmabadi · 2024-11-13T20:02:07Z

CyrusNajmabadi
Nov 13, 2024
Collaborator Author

@julealgon Feel free to open a discussion on this. This issue is not the location to meta discus process.

[Proposal]: Raw string literal #8646

CyrusNajmabadi Jan 6, 2021 Collaborator

Raw string literal

Summary

Replies: 329 comments

CyrusNajmabadi Jan 6, 2021 Collaborator Author

CyrusNajmabadi Jan 6, 2021 Collaborator Author

CyrusNajmabadi Jan 6, 2021 Collaborator Author

CyrusNajmabadi Jan 6, 2021 Collaborator Author

This comment has been minimized.

CyrusNajmabadi Jun 10, 2023 Collaborator Author

CyrusNajmabadi Jun 10, 2023 Collaborator Author

CyrusNajmabadi Jun 10, 2023 Collaborator Author

CyrusNajmabadi Nov 13, 2024 Collaborator Author

This comment was marked as off-topic.

CyrusNajmabadi Nov 13, 2024 Collaborator Author

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

CyrusNajmabadi
Jan 6, 2021
Collaborator

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

CyrusNajmabadi
Jan 6, 2021
Collaborator Author

CyrusNajmabadi
Jun 10, 2023
Collaborator Author

CyrusNajmabadi
Jun 10, 2023
Collaborator Author

CyrusNajmabadi
Jun 10, 2023
Collaborator Author

CyrusNajmabadi
Nov 13, 2024
Collaborator Author

CyrusNajmabadi
Nov 13, 2024
Collaborator Author