I'm now 99% sure that { } best serves its purpose as a string form.
But there were several talking points that came out of that discussion. One was a desire for "raw" strings.
This is the idea that outside of the termination sequence, there's no escaping. This means you can put pretty much anything in the string. Backslashes, carets...it's all fair game.
Two Very Different String Forms: When Are They Raw?
To me, it made the most sense that the raw form be the braced form...because it is so frequently applied to sections of arbitrary documentation text (such as the Description: in module headers).
Description: {
If you call this from C, then write:
if (a ^ b != 0) { // bitwise XOR
printf("This is an example\n");
}
So there you see carets and backslashes working.
}
With binding support for string interpolation, we can imagine this getting even more useful for representing snippets of other languages with escaped portions inside of them.
However, @giuliolunati favored the idea of making quoted strings mostly-raw, because there was an easy-seeming way to escape quotes using only the quote character.
>> "This would be ""quotes"" inside a string"
== {This would be "quotes" inside a string}
How braces are escaped historically ( e.g. ^} ) is messier. That drags caret into it, so now you're worrying about needing to escape carets and braces. A more uniform approach appealed to Giulio, so he favored the quotes form...and would prefer it to be able to represent characters "as-is" by default, with this exception for embedded quotes.
But from my point of view, I was seeking to avoid is any need to do search/replace on the embedded information. So mostly-raw wasn't good enough; e.g. I'd like to copy and paste the C code out of the example above, not have its quotes doubled:
Description: "
if (a ^ b != 0) { // bitwise XOR
printf(""This is an example\n""); <-- doubled quotes not good
}
"
We also discussed that I'm averse to having ordinary quotes as multi-line strings... though maybe we should allow them. :-/ But even if we did, it feels unintentionally incomplete to see something like:
Description: "
So for these reasons I wanted to focus the raw string effort on braced strings. Yet there are a lot of things that it gets hard to represent in a raw string form when you try to use unmatched braces in the content.
After thinking about it a bit, we came up with the option of being able to set the delimiter according to a number of braces and a vertical bar.
{...} ; expects any { } inside to be matched pairs
{|...|} ; allows internal unpaired and mismatched { }, {| |} matched pairs
{{|...|}} ; allows internal unpaired and mismatched {| |}, {{| |}} matched
etc. etc.
This can handle some pretty sticky strings like {|ab"c"} {"d"ef|} if need be, where the data extracted is:
ab"c"} {"d"ef
The approach would allow any number of {{ }}, which sounds like it could get ugly. But it's kind of like generic quoting, where I don't anticipate people using ridiculously high levels like {{{{|...|}}}}. But having it be a general method has value--especially in generated code scenarios.
Strings starting or ending with vertical bar forms like {|} get sacrificed, so you'll have to use "|" instead. But you would use "}" so this just moves | into the same category as } and {.
I also suggested an additional rule...that you don't terminate braced strings except as:
- {...} -space-
- {...} -newline-
- {...}]
- {...})
If we limit it to these possibilities, you can write things like:
code: {char c = '}';}
It seems that a lot of unpaired brace cases are single character literals like this, which don't fall under the rule. You might want to put the bars in for good measure anyway:
code: {|char c = '}';|}
In any case, the other thing we were leaning toward here was that when quoted strings are escaped, they do so compatibility with the classical C backslashes, based on the idea that caret escaping hadn't done the language any particular favors.
Just wanted to write this up while I still was thinking about it... 
