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