4 ms·

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

• Someone1234 5y ago
  > I'm surprized this is not already in the language. Because it is already in the language. var xml = @" <element attr=""content""> <body> </body> </element>"; This proposal mostly seems to be about some edge case where @" " syntax isn't good enough. But really, this whole thing is an improvement to an anti-pattern, and you should instead be looking into not needing multi-line block specific string literals in your code (e.g. putting templates in their own files/resources).
  • maybeOneDay 5y ago
    You've perfectly demonstrated one motivation for this proposal: your string literal is incorrect. Verbatim strings in C# require " to be escaped, your string should be: var xml = @" <element attr=""content""> <body> </body> </element>";
    • Someone1234 5y ago
      All it perfectly demonstrates is that this is inherently an anti-pattern and that we're discussing features to work around things you shouldn't be doing to begin with. If you want to store XML literals, then by all means do so, but within the code itself is inappropriate. Even the existing @" " syntax is a code-smell, the new syntax doesn't address why that is (e.g. validation/colorization/etc don't work for string literals containing arbitrary other languages). .Net already has constructs to allow the dynamic creation of XML blocks (and JSON) without resorting to string-comcat shenanigans.
      • maybeOneDay 5y ago
        Anti-patterns are rarely as absolute as you're making this out to be. Sure, I agree, lots of times it's better to store xml or json literals not in code. But for something three lines long it's perfectly fine, more readable, and trivial. This new proposal makes it elegant to do so, the only issue is that the @"" syntax should never have been used and unfortunately now we are proposing a third string literal syntax. That I don't like.
      • weq 5y ago
        18yrs of C# here and i say YES PLEASE to this feature. $@ does not cut work for this use-case and string processing has always been a performance bottleneck. Times have changed, xml/web is becoming ubitiqos... espically in LOB apps where u can use WebView based frameworks to create cross-platform apps that share 99% of code.
  • tialaramex 5y ago
    Microsoft's "verbatim strings" aren't. Think of them instead as "Oops, we use a lot of backslashes here at Microsoft and over time that just looks more and more stupid" strings and then these actual raw strings make lots more sense than those did. There's plenty of stuff in a middle ground where a separate template file is a waste. Your example, now that you've corrected it shows that nicely. A separate template would be a waste here for these few bytes, and yet "verbatim strings" mean instead of this just being some actual XML you can copy-paste it has to be escaped / unescaped. If your issue is that you don't think string literals should be a thing at all, C# is the wrong language for you. Try one of the early numeric langauges, or something modern like WUFFS that eschews strings entirely because they're too dangerous. Once you accept that literals should be a thing (notice these aren't interpolated, they're just literals) this is an obvious idea. The bad "verbatim" syntax should go away in favour of a raw literal syntax such as the one proposed here.
• Metasyntactic 5y ago
  Hi. I'm the designer of this feature. The reason for this is so that we can potentially have fenced string blocks in the future. for example: ```c# var s = """xml <Book><title/></Book> """; ``` and the like. Thanks!
  • captainmuon 5y ago
    Thanks for chiming in, that makes sense! I probably would have put the prefix before the quotes, so it matches `@"..."` and the usage in C++ and Python. But there is probably a reason why that is not possible: var s = xml"""<Book><title /></Book>""";