[swift-evolution] multi-line string literals.

Brent Royal-Gordon brent at architechies.com
Sat Apr 23 18:54:11 CDT 2016

> Instead of creating yet another set of string quotation rules, I would prefer copy & pasting the Perl 5 rules :)

I wouldn't.

I'm a big fan of Perl. It was my daily driver for many years. I participated in the Perl 6 design process, was pumpking for a Parrot (the early Perl 6 interpreter) subsystem, and have patches in the Perl 5 interpreter. I'm fluent in Perl 5's various literal syntaxes. (Actually, a piece of syntax I added had to be disambiguated from empty-regex.)

I've used and appreciated virtually all of Perl's literal syntaxes, but I don't think they'd be a good fit for Swift.

Every language has its own character. Perl's is that it's maximally expressive and deeply embraces precedent from other languages, even at the cost of making code ambiguous, obscure, or downright ugly. In that context, having two quoting mechanisms (q and qq) in three forms ('/", q/qq, heredoc) is a great solution, and the lack of indentation handling is not a big deal. It fits perfectly into Perl's concept of TMTOWTDI ("there's more than one way to do it").

Swift's character is quite different from Perl's, though. Swift aims to be simple and clear, permitting shorthands, omissions, and inferences, but usually not outright redundancy. If the language is making something difficult, you should enhance an existing construct, not create a new one:

* Too much junk in a closure declaration? Let people omit inferrable types or even parameter names.
* Immutable collections too slow, mutable ones too dangerous, and having both is an ugly compromise? Make them value types, giving you the best of both worlds.
* String and Array are kind of similar, but not really the same? Unite them with common protocols. (And if Int indexing is too dangerous for Strings, use an associated type to make sure Strings can use a safely opaque Index.)

The huge preponderance of quoting syntaxes in Perl isn't very Swifty, but neither is the decision to leave a major style issue (indentation) on the table. Swift generally does not tolerate designs that lead to ugly code.

If I had to create a slogan like TMTOWTDI for Swift, I would probably choose "one way, maximally elegant". That's quite a different approach to language design, and it calls for a different approach to string literals.

Brent Royal-Gordon

More information about the swift-evolution mailing list