Recently I was debugging a piece of code that interfaced with gettext’s PO file-format. This is a file-format that contains quoted strings such as
msgid "Hello %s\n"
In the instance, that string had been (somehow) escaped again by some processing machinery, so instead it was
msgid "Hello %s\\\n"
which was the source of some bugs. This is a perennial problem when dealing with strings that are meant to contain non-printable data: do those non-printable glyphs get included directly? Do they get rendered as escapes? If so, what is the syntax for the escapes? If there is already-escaped text, do we escape it again? etc.
Using raw-string literals makes this problem go away to a large extent: you simply enclose the data with some delimiter that doesn’t appear in the literal, and you’re -done-. So the above example could have been:
msgid R"foo(Hello %s\n)foo"
or
msgid {bar|Hello %s\n|bar}
and it’s completely clear what is meant.
It seems like this would be a good thing for the SEXP data-format to support on input. Perhaps even (via a special pretty-printer) on output (inspect each atom and for those that contain non-printable glyphs, infer a good delimiter and emit a raw-string literal).
P.S. I’m aware that the code for this is straightforward. The hard part is achieving agreement to make the change, not actually making it.
P.P.S. Of course, there are other examples besides this one. Anytime you want to use a file-format for more than data-interchange (when a human is meant to actualy read and modify (or author) the file), you can encounter the problem. So it happens with cppffigen 's IDL files.