Raw string literals: learning from Swift

[Guy Steele]

I like it.

There is an advantage to using a visually heavyweight character like ‘#’.  If you don’t want to use that, I think ‘$’ would work.

(I considered ‘%’, but there are two problems: in familiar usage it occurs a lot in format strings (even more than ‘$’), and moreover in principle the string

	%”

can already occur in a legitimate Java program (consider `myVar%”foobaz”.substring(k).length()`), but I think

	$”

cannot.)

I like that it leaves open a variety of escape constructions for possible future use.

> On Jan 11, 2019, at 2:16 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Received on the -comments list.
> 
>> Begin forwarded message:
>> 
>> From: Fred Curts <fred.curts at icloud.com <mailto:fred.curts at icloud.com>>
>> Subject: Raw string literals: learning from Swift 
>> Date: January 11, 2019 at 2:15:10 PM EST
>> To: amber-spec-comments at openjdk.java.net <mailto:amber-spec-comments at openjdk.java.net>
>> 
>> With Swift 5 recently adding custom String delimiters (also called raw string literals), I find the design of Swift's string literals very compelling, more so than other languages I've studied.
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md <https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md> <https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md <https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md>> (implemented in Swift 5)
>> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md <https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md> <https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md <https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md>> (implemented in Swift 4)
>> https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID286 <https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID286> <https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID286 <https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID286>>
>> 
>> Here is what I like about Swift's string literals. In no particular order:
>> 
>> 1. Multi-line and raw string literals are orthogonal features.
>> (Try adding a literal dollar sign to a Kotlin multi-line string literal and you'll know what I mean.)
>> 
>> 2. Custom string delimiters solve all the use cases for raw string literals but nevertheless support escape sequences and interpolation expressions.
>> I've personally come across this need many times when trying to build larger regular expressions or code snippets out of smaller ones.
>> 
>> 3. Escape sequences and interpolation expressions use the same escape character.
>> This simplifies matters considerably, in particular once custom string delimiters are added to the mix.
>> (Having multiple custom escape characters would be too much.)
>> 
>> 4. Multi-line string literals are delimited by triple double quotes.
>> This makes them visually compatible with but heavier than single-line string literals, which seems like a good fit.
>> Distinct delimiters for single-line and multi-line string literals seem like a win for both humans and parsers.
>> For example, it's easy to tell where the missing end quote of a single-line string literal belongs.
>> 
>> 5. It's easy to control line indentation of multi-line string literals and leading and trailing whitespace of the entire string.
>> All of this is settled at compile time.
>> 
>> 6. Opening and closing delimiters of multi-line string literals must be on their own line.
>> This avoids headaches with edge cases such as string literals ending with two double quotes.
>> 
>> 7. Multi-line string literals with custom string delimiters can contain arbitrarily long sequences of double quotes.
>> 
>> I hope I've convinced you that the design of Swift's string literals is worth a closer look.
>> 
>> -Fred
>