[swift-evolution] multi-line string literals

Chris Lattner clattner at apple.com
Thu Dec 10 19:41:31 CST 2015

> On Dec 10, 2015, at 1:56 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.

I’m positive about adding some syntax for multi-line string literals.  Some questions to think about and debate on this list:

1) What concrete syntax should be used?  There are a lot of options in this space across a wide range of languages.  C++ has raw strings, and this page has more examples:

2) Should escapes like \n be processed always, should they never be processed, or should they be processed by default but disable-able in the syntax?

3) What other policy decisions make sense to expose on these literals?  Since this will be the “powerful form of string literals”, it makes sense to be the place to put weird knobs that are seldom used but important in various cases.

I assume that this would tie into the existing literal convertible protocols, and if/when escaping is supported that it would support interpolation as well.


> My initial improvement request is here: https://bugs.swift.org/browse/SR-170 <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 <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/59949df4/attachment.html>

More information about the swift-evolution mailing list