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.go...@oracle.com> wrote:
>
> Received on the -comments list.
>
>> Begin forwarded message:
>>
>> From: Fred Curts <fred.cu...@icloud.com <mailto:fred.cu...@icloud.com>>
>> Subject: Raw string literals: learning from Swift
>> Date: January 11, 2019 at 2:15:10 PM EST
>> To: amber-spec-comme...@openjdk.java.net
>> <mailto:amber-spec-comme...@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
>
