> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
