title: What is the rationale for parenthesis in C++11's raw string literals R"(...)"?
body: <p>There is a very convenient feature introduced in C++11 called raw string literals, which are strings with no escape characters. And instead of writing this:</p>
  
  <pre><code>  regex mask("\\t[0-9]+\\.[0-9]+\\t\\\\SUB");
  </code></pre>
  
  <p>You can simply write this:</p>
  
  <pre><code>  regex mask(R"(\t[0-9]+\.[0-9]+\t\\SUB)");
  </code></pre>
  
  <p>Quite more readable. However, note extra parenthesis around the string one have to place to define a raw string literal. </p>
  
  <p>My question is, why do we even need these? For me it looks quite ugly and illogical. Here are the cons what I see:</p>
  
  <ul>
  <li>Extra verbosity, while the whole feature is used to make literals more compact</li>
  <li>Hard to distinguish between the body of the literal and the defining symbols</li>
  </ul>
  
  <p>That's what I mean by the hard distinguishing:</p>
  
  <pre><code>"good old usual string literal"
   ^-    body inside quotes   -^
  
  R"(new strange raw string literal)"
     ^- body inside parenthesis  -^
  </code></pre>
  
  <p>And here is the pro:</p>
  
  <ul>
  <li>More flexibility, more characters available in raw strings, especially when used with the delimiter: <code>"delim( can use "()" here )delim"</code></li>
  </ul>
  
  <p>But hey, if you need more flexibility, you have old good escapeable string literals. Why the standard committee decided to pollute the content of every raw string literal with these absolutely unnecessary parenthesis? What was the rationale behind that? What are the pros I didn't mention?</p>
  
  <p><strong>UPD</strong> The answer by Kerrek is great, but it is not an answer, unfortunately. Since I already described that I understand how it works and what benefits does it give. Five years passed since I've asked this question, and still there is no answer. And I am still frustrated by this decision. One could say that this is a matter of taste, but I would disagree. How many spaces do you use, how do you name your variables, is this <code>SomeFunction()</code> or <code>some_function()</code> - this is the matter of taste. And I can really easily switch from one style to another.</p>
  
  <p>But this?.. Still feels awkward and clumsy after so many years. No, this is not about the taste. This is about how we want to cover all possible cases no matter what. We doomed to write these ugly parens every time we need to write a Windows-specific path, or a regular expression, or a multi-line string literal. And for what?.. For those rare cases when we actually need to put <code>"</code> in a string? I wish I was on that committee meeting where they decided to do it this way. And I would be strongly against this really bad decision. I wish. Now we are doomed.</p>
  
  <p>Thank you for reading this far. Now I feel a little better.</p>
  
  <p><strong>UPD2</strong> Here are my alternative proposals, which I think both would be MUCH better than existing.</p>
  
  <p>Proposal 1. Inspired by python. Cannot support string literals with triple quotes: <code>R"""Here is a string literal with any content, except for triple quotes, which you don't actually use that often."""</code></p>
  
  <p>Proposal 2. Inspired by common sense. Supports all possible string literals, just like the current one: <code>R"delim"content of string"delim"</code>. With empty delimiter: <code>R""Looks better, doesn't it?""</code>. Empty raw string: <code>R""""</code>. Raw string with double quotes: <code>R"#"Here are double quotes: "", thanks"#"</code>.</p>
  
  <p>Any problems with these proposals?</p>