[swift-evolution] multi-line string literals.

[John Holdsworth]

It’s +1 from me also. Swift’s Lexer is less than 2000 lines in it’s entirety whereas Perl’s
tokeniser is more than 11,000 lines so I don’t think this is a direction we want to head in.

Besides, I don’t feel there is a need for more than one type of string as Swift's
\() interpolation syntax is sufficiently distinct that needing an un-interpolated
string is comparatively rare. With respect to the “picket fence” problem with
complex regular expressions one proposal is that unknown escape sequences 
be passed into the string literal instead of giving an error. This would make the
following a legal string/regex: “\w[\w\d]+”. This involves a shift from thinking of
\ as an escape character. More specific supported escape sequences \r \n \( etc.

This leaves the question of indentation inside string. I’d prefer not to address this
as it prevents data being pasted directly into a program and on KISS grounds.
If someone suggests a simple consistent syntax however I could take a look at it.

If you want to give the proposal a test drive you can download a 3.0 toolchain
supporting multiline strings including the regex suggestion installing it as follows :

$ curl http://johnholdsworth.com/swift-LOCAL-2016-04-24-a-osx.tar.gz > multiline.tar.gz
$ sudo tar xfz multiline.tar.gz -C /

Select "Local Swift Development Snapshot 2016-04-24” in preferences and restart Xcode.

John

> On 24 Apr 2016, at 04:31, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 
> +1 for Brent's comments 
> 
> On Sunday, 24 April 2016, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > 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
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> -- 
> -- Howard.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160424/da614858/attachment.html>