[swift-evolution] multi-line string literals.

[Cole Campbell]

> I think we should definitely propose the items in "Absolutely Necessary" and consider proposing the ones in "Really Nice To Have" for Swift 3. I think we should definitely do the "Really Nice To Have, But We Can't" item in Swift 4. I think we should revisit and consider the others in Swift 4 and beyond.

Okay thanks. I wanted to make sure I wasn’t cluttering the thread with off-topic conversation. I agree with how you’ve prioritized the items for proposal.

> I have intentionally described these features very broadly. For instance, I said "alternate delimiters", not "the `_` modifier". The specific designs I sketched in the proposal are merely examples of solutions to that class of problem. Here are a whole slew of other designs just for alternate delimiters:
> 
> * Use a different identifier-but-not-capitalizable character, like `$`.
> * Use a different single-character ASCII delimiter, like `'`.
> * Use a different multi-character delimiter, like `"""`.
> * Use a different Unicode delimiter, like smart quotes (`“foo ”`) or French quotes (`«foo»`) or Japanese quotes (`⸢foo⸥`).
> * Permit arbitrary delimiters bounded by some specific, known character, like (just making this up) `'~~~~~'`.
> 
> That's just off the top of my head—there are probably a hundred more of these. What is presented in the "Future directions for string literals" section is a series of *example* solutions to illustrate the problems that need solving, not necessarily the exact thing we must write a proposal for in a few months or years. It's a sketch, not a roadmap.

I actually really like the examples of delimiters you sketched out in the proposal.

I have an idea for `_` as a modifier. What if it indicated that everything within the string literal is taken as part of the literal? All escapes are disabled and internal quotes are allowed. The `_` is already used to indicate in Swift when a value will not be used, so it follows (maybe?) that with strings it indicates that nothing in the literal will be evaluated. No expressions are ‘used’, so to speak.

The other suggestion I would make is to only use the `_` modifier at the beginning, unless I’m missing a reason why the compiler would need it at the end as well. I just bring it up because that is one less thing to forget to ‘close’ at the end, and it’s cleaner.

Here’s an example:

let string = _”This “string” allows anything
		“\(thisWillNotBeEvaluated)
		“Neither will these:
		“\w+\n
		“3 “slashes" are fine too: \\\
		“etc. etc.”