[Someone1234]

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]

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]

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.