[swift-evolution] multi-line string literals

Travis Tilley ttilley at gmail.com
Thu Dec 10 18:58:34 CST 2015

If implemented as an argument to `Lexer::lexStringLiteral()`, then it would
behave exactly like a typical string literal except where multi-line
behavior is concerned (and being terminated by triple quotes instead of a
single quote). This would include interpolation, as well as any future

The function in question wouldn't require much modification:

As well as slight modification here to detect triple quoted strings and
pass on that information:

But that would be an implementation detail, and only if others agree to
using triple quote syntax.

- Travis Tilley

On Thu, Dec 10, 2015 at 5:43 PM, Tal Atlas <me at tal.by> wrote:

> Conceptually for this, especially for server side utility. I think there’s
> a plethora of options out there, “”” seems to be the most modern one, and
> i’d vote for it having the same interpolation as standard strings \()
> On Thu, Dec 10, 2015 at 4:57 PM Travis Tilley via swift-evolution <
> swift-evolution at swift.org> wrote:
>> I would very much like to implement multi-line string literals in swift
>> and get feedback on what this should look like, as i've been informed there
>> are several competing suggestions filed as radars.
>> My initial improvement request is here:
>> https://bugs.swift.org/browse/SR-170
>> It is only an opinion, but it's my belief that simple python-style
>> multi-line string literals are the way to go. They're simple and, in the
>> end, exactly the same as normal string literals. They begin and end with
>> triple quotes, can contain newlines, can contain single quotes, and that's
>> all that's special in their parsing. The same block of code in Lexer.cpp
>> could be used for both types of literal, ensuring behavior is always
>> consistent regardless of any future changes.
>> There is also the potential suggestion of removing consistent indentation
>> if there is any so as to make formatting of a multi-line string literal
>> look more clean when indented. For me, it would be a nice to have, but not
>> a make or break feature... and for some it may be confusing.
>> I'd like to state that I'm not proposing heredoc-style functionality, as
>> I believe that to be an entirely separate feature. The potential to have
>> one heredoc embedded within another would certainly make parsing more
>> painful than i'm happy with.
>> For an example of code that would benefit significantly from multi-line
>> string literals, please look at docopt.swift:
>> https://github.com/docopt/docopt.swift/blob/master/Examples/Swift/arguments_example/main.swift#L9-L25
>> Docopt does the opposite of what most command line argument libraries do:
>> rather than defining options and auto-generating the help text based on
>> that... You write the help text and it auto-generates a CLI with exactly
>> those options and arguments. It makes writing CLI applications an absolute
>> pleasure, but without multi-line string literals in swift it's currently
>> less pleasant than it could be.
>> Please send me your thoughts. ^_^b
>> -Travis Tilley
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/b30c3b92/attachment.html>

More information about the swift-evolution mailing list