<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">It’s +1 from me also. Swift’s Lexer is less than 2000 lines in it’s entirety whereas Perl’s<div class="">tokeniser is more than 11,000 lines so I don’t think this is a direction we want to head in.</div><div class=""><br class=""></div><div class="">Besides, I don’t feel there is a need for more than one type of string as Swift's</div><div class="">\() interpolation syntax is sufficiently distinct that needing an un-interpolated</div><div class="">string is comparatively rare. With respect to the “picket fence” problem with</div><div class="">complex regular expressions one proposal is that unknown escape sequences </div><div class="">be passed into the string literal instead of giving an error. This would make the</div><div class="">following a legal string/regex: “\w[\w\d]+”. This involves a shift from thinking of</div><div class="">\ as an escape character. More specific supported escape sequences \r \n \( etc.</div><div class=""><div class=""><br class=""></div><div class="">This leaves the question of indentation inside string. I’d prefer not to address this</div><div class="">as it prevents data being pasted directly into a program and on KISS grounds.</div><div class="">If someone suggests a simple consistent syntax however I could take a look at it.</div><div class=""><br class=""></div><div class="">If you want to give the proposal a test drive you can download a 3.0 toolchain</div><div class="">supporting multiline strings including the regex suggestion installing it as follows :</div><div class=""><br class=""></div><div class="">$ curl <a href="http://johnholdsworth.com/swift-LOCAL-2016-04-24-a-osx.tar.gz" class="">http://johnholdsworth.com/swift-LOCAL-2016-04-24-a-osx.tar.gz</a> > multiline.tar.gz</div><div class="">$ sudo tar xfz multiline.tar.gz -C /</div><div class=""><br class=""></div><div class="">Select "Local Swift Development Snapshot 2016-04-24” in preferences and restart Xcode.</div><div class=""><br class=""></div><div class="">John</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 24 Apr 2016, at 04:31, Howard Lovatt <<a href="mailto:howard.lovatt@gmail.com" class="">howard.lovatt@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">+1 for Brent's comments <span class=""></span><br class=""><br class="">On Sunday, 24 April 2016, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Instead of creating yet another set of string quotation rules, I would prefer copy & pasting the Perl 5 rules :)<br class="">
<br class="">
I wouldn't.<br class="">
<br class="">
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.)<br class="">
<br class="">
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.<br class="">
<br class="">
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").<br class="">
<br class="">
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:<br class="">
<br class="">
* Too much junk in a closure declaration? Let people omit inferrable types or even parameter names.<br class="">
* 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.<br class="">
* 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.)<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
--<br class="">
Brent Royal-Gordon<br class="">
Architechies<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote><br class=""><br class="">-- <br class="">-- Howard.<br class="">
</div></blockquote></div><br class=""></div></div></body></html>