> On Apr 23, 2016, at 2:08 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>> I’m trying to avoid more advanced features such as the handling of indenting
>> which
>> for me complicates something that if kept simple can be documented very
>> easily.
>
> I don't think you can tackle multiline strings without worrying about
> indenting. Indentation may fundamentally change the approach you choose.
I agree with this and almost every point you make in your email (and your other
subsequent one about one approach maximally general). That said, I wonder if
there is a different conclusion that can be reached. I’m going to rearrange
your three features a bit:
> The way I would prefer to tackle these is:
>
> * Multiline literals: If the closing quote of a string is not present, look
> at the next line. If it consists of (optional) indentation followed by a
> matching opening quote, the string has a newline and then continues after the
> quote on the next line. (The handling of comments is an open question here.)
>
> let xml: String = "<?xml version=\"1.0\"?>
> "<catalog>
> "\t<book id=\"bk101\" empty=\"\">
> "\t\t<author>\(author)</author>
> "\t</book>
> "</catalog>"
>
> The cool things about this are that (a) the compiler can tell you really do
> mean this to be part of the literal and you haven't just forgotten to close
> the string, and (b) there's no guesswork about how indentation should be
> handled. The uncool thing is that you need to insert the quote at the
> beginning of each line, so you can't just blindly paste into a multiline
> literal. Editors can help make that easier, though—a "paste as string
> literal" feature would be a nice addition to Xcode, and not just for
> multiline strings or just for Swift.
Yes, I completely agree. This is is awesome, and a nice & simple
generalization of our existing syntax. It has obvious behavior even if you
encounter it in code without knowing about the feature.
> * Disabling escapes: If you use single quotes instead of double quotes,
> backslash escapes are disabled.
We need a way to disable escapes, but it seems to me that (since it is
orthogonal to the other concerns) that it should not be tied to the “multiple
single quotes” syntax. What is your thought on “modifier” prefix characters
for string literals? e.g.:
let x = e”no \escapes \(processed here”
If we supported these, they would be supported with multi-line string literals
by putting the modifiers on the first line of the literal, and the multi-line
approach above would “just work”. You could introduce several different
modifiers, e.g. one that disabled general escapes, but still allowed \(x) for
substitution.
> * Yes, with a number of backslashes matching the number of quotes, which
> allows you to insert literal \( text: '''
> <author>\\\(author)</author>
Egads!
> Notes on alternatives:
>
> 1. If you wanted to not provide no-escaping strings, an alternative would be
> to say that *all* escapes require as many backslashes as there are quotes in
> the string delimiter. Thus, a newline escape in a `"""` string would be
> `\\\n`. This would in practice give you the same flexibility to write a
> literal without worrying (much) about escaping.
I’m really not a fan of requiring “stacking” of escapes to re-enable them.
This (IMO) just makes it less likely that you’ll run into an edge case. I also
don’t like the “fix" being to have to use 5 quotes around your strings :-)
> 3. It might be useful to make multiline `"` strings trim trailing whitespace
> and comments like Perl's `/x` regex modifier does.
If you have modifier characters already, it is easy to build a small zoo full
of these useful beasts.
> * Alternative delimiters: If a string literal starts with three, or five, or
> seven, or etc. quotes, that is the delimiter, and fewer quotes than that in a
> row are simply literal quote marks. Four, six, etc. quotes is a quote mark
> abutting the end of the literal.
>
> let xml: String = """<?xml version="1.0"?>
> """<catalog>
> """\t<book id="bk101" empty="">
> """\t\t<author>\(author)</author>
> """\t</book>
> """</catalog>"""
>
> You can't use this syntax to express an empty string, or a string consisting
> entirely of quote marks, but `""` handles empty strings adequately, and
> escaping can help with quote marks. (An alternative would be to remove the
> abutting rule and permit `""""""` to mean "empty string", but abutting quotes
> seem more useful than long-delimiter empty strings.)
I agree that there is a need to support alternative delimiters, but
subjectively, I find this to be pretty ugly. It is also a really unfortunate
degenerate case for “I just want a large blob of XML” because you’d end up
using “"” almost all the time, and you have to use it on every line.
For cases like this, I think it would be reasonable to have a “heredoc” like
scheme, which does not allow leading indentation, and does work with all the
same modifier characters above. I do not have a preference on a particular
syntax, and haven’t given it any thought, but this would allow you to do things
like:
let str = <<EOF
<?xml version="1.0"?>
<catalog>
\t<book id="bk101" empty="">
\t\t<author>\(author)</author>
\t</book>
</catalog>
EOF
for example. You could then turn off escaping and other knobs using the
modifier character (somehow, it would have to be incorporated into the syntax
of course).
I generally agree with your down thread remarks about how Swift doesn’t like to
have multiple different solutions for the same problem. OTOH, you could look
at “” syntax as being analogous to closure exprs, and heredoc syntax as being
analogous to nested functions :-)
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
