[swift-evolution] multi-line string literals

Alex Gordon alextgordon at gmail.com
Mon Dec 14 14:22:42 CST 2015

I think that reasoning would have been solid for C in 1970. However,
re-evaluating it in the context of 2015...

1) It does not appear to be a source of problems in any of the languages
that do support it.

2) Modern text editors and IDEs have quote balancing, so it is a lot harder
to forget a quote than it used to be.

3) Compile-time is actually too late to be catching lexical errors: it's a
last resort. Lexical errors should be visible in the editor, e.g. syntax
highlighting. If you forget a quote, the non-string code underneath will be
coloured like a string.

4) Even if quote balancing fails, and even if you don't notice from syntax
highlighting, the compiler can still try to provide good error messages
because in most cases the syntax error will be an unexpected identifier
after a multi-line string. e.g.

    print("Hello   <- missing quote

    The identifier World is unexpected, so the compiler can track back and
figure out that the source was at "Hello...

- Alex

On Mon, Dec 14, 2015 at 7:06 PM, Andrey Tarantsov <andrey at tarantsov.com>

> What is the reason that normal strings "..." don't support newlines? It's
>> not traditionally seen in C-inspired languages, but it's hardly unusual
>> outside that sphere[*]. Ruby and HTML are probably the most common
>> examples, but apparently OCaml and Lisps also allow it?
> You'd have to ask Chris Latter and Dmitri Gribenko, who are responsible
> for the lines in Lexer.cpp that prevent it:
> The obvious reason is to catch a missing quote early, with a better error
> message. I believe it should stay that way, because multiline strings are a
> lot less widespread.
> A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/e0e3350f/attachment.html>

More information about the swift-evolution mailing list