Correct, there is no released version of swift that used ‘’ for anything, feel free to send a PR that rips them out completely.
-Chris
···
On Dec 14, 2015, at 12:54 PM, Travis Tilley via swift-evolution <swift-evolution@swift.org> wrote:
Chris Lattner has also stated that he has no problem ripping out the current compatibility logic for single quotes. What I'd really like to know is if it would require multiple releases to properly handle changing their behavior. If my currently limited understanding of Lexer.cpp is correct, people are -already- being warned about using single quoted strings, so I wouldn't feel bad about that behavior changing out from under them to suddenly be unescaped.
I was going to wait a week to write up an actual official proposal and
submit a pull request to swift-evolution, but at 67 emails this has already
received a lot more feedback than most other topics already. It might not
be worth it to wait so long.
What I would really like to see is more use cases than my own and the
couple others we've seen in this thread. The SQL example showed me that the
indentation erasure rules might not be as simple as I assumed (which is a
good thing). The JSON example showed me that having unescaped syntax for
raw strings is also vital. Please keep the use cases coming, as my own
(docopt) really isn't all that complicated.
Chris Lattner has given a solid reason why extending normal strings to
multiple lines isn't the best of all potential options. I don't feel
strongly enough about the issue to argue one way or another and am inclined
to not change existing behavior.
Chris Lattner has also stated that he has no problem ripping out the
current compatibility logic for single quotes. What I'd really like to know
is if it would require multiple releases to properly handle changing their
behavior. If my currently limited understanding of Lexer.cpp is correct,
people are -already- being warned about using single quoted strings, so I
wouldn't feel bad about that behavior changing out from under them to
suddenly be unescaped.
I haven't delved much into the use cases for prefix/suffix extensions and
would like to hear more about this.
I think that reasoning would have been solid for C in 1970. However,
re-evaluating it in the context of 2015...
1) It does not appear to be a source of problems in any of the languages
that do support it.
2) Modern text editors and IDEs have quote balancing, so it is a lot harder
to forget a quote than it used to be.
3) Compile-time is actually too late to be catching lexical errors: it's a
last resort. Lexical errors should be visible in the editor, e.g. syntax
highlighting. If you forget a quote, the non-string code underneath will be
coloured like a string.
4) Even if quote balancing fails, and even if you don't notice from syntax
highlighting, the compiler can still try to provide good error messages
because in most cases the syntax error will be an unexpected identifier
after a multi-line string. e.g.
print("Hello <- missing quote
print("World")
The identifier World is unexpected, so the compiler can track back and
figure out that the source was at "Hello...
- Alex
···
On Mon, Dec 14, 2015 at 7:06 PM, Andrey Tarantsov <andrey@tarantsov.com> wrote:
What is the reason that normal strings "..." don't support newlines? It's
not traditionally seen in C-inspired languages, but it's hardly unusual
outside that sphere[*]. Ruby and HTML are probably the most common
examples, but apparently OCaml and Lisps also allow it?
You'd have to ask Chris Latter and Dmitri Gribenko, who are responsible
for the lines in Lexer.cpp that prevent it:
The obvious reason is to catch a missing quote early, with a better error
message. I believe it should stay that way, because multiline strings are a
lot less widespread.
What syntax would *you* personally prefer for unescaped strings?
'''
this doesn't do anything:
\
\n \t \a
moo cow
'''
and:
'\'
Or:
r"""
this doesn't do anything:
\
\n \t \a
moo cow
"""
and:
r"\"
...perhaps with a capital R. Maybe an RC or RS instead (for raw characters
or raw string).
The single quote version is more consistent with other languages with this
feature (ruby, perl, bourne, other shells). It would also be easier to
parse and allow you to define the resulting type after the variable rather
than inferring from the literal (which is how I prefer
StringLiteralConvertible to work, at least from current experience). You
can build some powerful code on top of StringLiteralConvertible and just
leaving the string literal *alone*.
The r/R/RC/RS prefix versions are consistent-ish sorta kinda-almost with
python, and might tie into the existing proposal for literal
prefixes/suffixes if that proposal is approved. The details of that would
have to be decided in the other thread, but I don't personally see that as
an obstacle for implementing the feature of enhanced multi-line and
unescaped strings first... even before other typing modifiers are decided
upon.
I prefer single quotes and triple single-quotes, as it feels more natural
and familiar for me *personally...* but either syntax would make me
significantly happier than not having one at all, and I haven't
internalized "the swift way" quite like the core team has.
Actually many text editors will cascade syntax highlighting on purpose, to
make it more visually obvious that you have forgotten a quote. Pretty much
every tmbundle supports cascading, including the one for Swift.
This is why text editors have autopair.
- Alex
···
On Mon, Dec 14, 2015 at 8:40 PM, Chris Lattner <clattner@apple.com> wrote:
On Dec 11, 2015, at 11:25 PM, Travis Tilley via swift-evolution < > swift-evolution@swift.org> wrote:
You'd have to ask Chris Latter and Dmitri Gribenko, who are responsible
for the lines in Lexer.cpp that prevent it:
On Sat, Dec 12, 2015 at 2:02 AM, Alex Gordon <alextgordon@gmail.com> > wrote:
What is the reason that normal strings "..." don't support newlines? It's
not traditionally seen in C-inspired languages, but it's hardly unusual
outside that sphere[*]. Ruby and HTML are probably the most common
examples, but apparently OCaml and Lisps also allow it?
Among other reasons, Swift’s current behavior makes it straight-forward
for the compiler to recover and handle the common error when you’ve
forgotten to close a “. If \n’s were allowed in simple string literals,
then everything to the end of the file is included in the string, and the
only mistake is the missing “. This may seem like a minor thing, but
matters a lot in an IDE context where you may have typed
let x = “foo
and just haven’t finished typing, and the entire buffer changes color or
something.