3) it's just cruel — xkcd: (
Only if your mental parser doesn’t match Swift’s. :^)
···
--
Brent Royal-Gordon
Architechies
@1: Or Xcode could simply continue the string if you hit enter without terminating it. (Same if you open a string literal, and then paste a multiline text)
To copy out of Xcode, use alt-click selection to cut away leading ".
@2: +1
@3: +1. Don't see the point why this should be better than simply adding strings up with +.
Generally, I'm kind of sceptical about this. Especially trailing whitespace becomes invisible.
You don't know if your editor cuts out trailing whitespace. You no longer see where each line ends.
Maybe with Xcode, the IDE could display kind of a rectangle that shows what's the left / right border of each line
(maybe background color the parts that are within the string, so you actually see trailing whitespace).
Still, even then I fail to see the real need for multiline string literals if you assume that your IDE is smart enough
to detect whether you are editing a string, and to automatically insert the " + on the current line and the indentation " on the next line
when you press enter or paste a multiline text in that context.
-1 for Heredoc proposal. It's just ugly, and even in languages that have it (e.g. PHP) I've never seen it used in current code,
with the exception of XML (where it's the only option I guess).
As for escaping vs non-escaping, just adding a few other languages as reference.
PHP uses " ... " to denote strings with interpolation and \n transformation etc., and ' ... ' for verbatim strings.
C# uses " ... " for normal strings and @" ... " for verbatim strings (e.g. Windows paths that incorporate lots of \).
Etan
···
On 14 Dec 2015, at 23:21, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org> wrote:
Yes, you are right, Brent, there should be a closing quote on the last line otherwise it would be a syntax error. That’s a much better idea! That would also fix the
let x = “foo
being valid syntax problem.
Guys, you know this is crazy, right? :-)
1) copy & paste would be really annoying (on that note, Xcode should totally get multiple cursors support like in Sublime)
2) any non-specialized syntax highlighter would parse them all completely incorrectly, which is not a show-stopper, but shouldn't be taken lightly. (Think a generic indented code block in Markdown on GitHub.)
3) it's just cruel — xkcd: (
<(.png>
A.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Yes, you are right, Brent, there should be a closing quote on the last line otherwise it would be a syntax error. That’s a much better idea! That would also fix the
let x = “foo
being valid syntax problem.
So, based on this idea, here’s what I propose. We have two orthogonal features:
ADJUSTABLE DELIMITERS:
Any odd number of “ characters can be used to delimit a quoted string. That means you can start and end one with “, “””, “””””, “””””””, etc. (In practice, more than three would probably only be used when generating code which itself includes multiline strings.) This only affects how many quotes in a row you have to backslash inside the string; it does not imply the string is multiline.
This is an interesting approach to avoid having to escape “’s in some common situations. One corner case: how do you write a string literal that starts or ends with “? How do you express the equivalent of “\”foo”? A concern is that this could make escape processing “feel” less predictable.
MULTILINE STRINGS:
If a quoted string does not terminate by the end of the line, Swift examines the next line of code. If that line starts with zero or more whitespace characters, followed by the same string delimiter used to open the string on the previous line, then the string literal includes the newline character at the end of the previous line and then continues on the next line.
If the next line has anything else before the delimiter—including a string delimiter which is not long enough, a comment, or a newline—Swift concludes that the string does not continue onto this line and emits an unterminated string error on the previous line. Thus, an unterminated multi-line string is always detectable in and of itself.
Swift does not do any other special processing of the string, like removing indentation (all indentation should be before the string delimiter on that line) or trimming newlines at the beginning or end. All escapes function as normal; any modification of escaping is reserved for other mechanisms outside the scope of this thread.
This sounds very interesting, and could be workable, I agree that this solves the error recovery problem. I still think we’d want a way to disable escape processing.
-Chris
···
On Dec 14, 2015, at 3:51 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
One corner case: how do you write a string literal that starts or ends with “? How do you express the equivalent of “\”foo”? A concern is that this could make escape processing “feel” less predictable.
Technically, the rule that there must be an odd number of double-quotes in the delimiter solves this: `“”””foo”””` can only be interpreted as `”foo` delimited by `“””`. But that’s obviously not an ideal answer.
One possibility is that, when you use a multi-character string literal delimiter, you could insert a single whitespace character after the opening delimiter (and any continuations on other lines), and before the terminating delimiter:
let foo = """ "To be, or not to be;
""" That is the question." "”"
// => “\”To be, or not to be;\n that is the question.\”"
To keep this from introducing ambiguity about whitespace stripping, the space would be required, and its absence would trigger a syntax error. I’m not totally satisfied with this approach, though.
I still think we’d want a way to disable escape processing.
I agree, but I think it’s orthogonal to this proposal. Whether we use `’foo'`, or `r”foo”`, or `@“foo”` (following C#), or `@raw “foo”`, that can easily extend to multiline and long-delimiter strings.
···
--
Brent Royal-Gordon
Architechies