Tracking the discussion, I’ve updated the prototype toolchain to support the
following types of string:
let multipart1 = "one" "two"
let multipart2 = “one\n"
“two\n"
let multipart3 = "one
“two\n"
let regex = e"\w[\w\d]*\n"
It can be downloaded here:
http://johnholdsworth.com/swift-LOCAL-2016-04-26-a-osx.tar.gz
Due to an implementation detail the e”” escaped strings still process escapes
and interpolation
which is how I would argue it should be anyway. The “e” modifier just mutes the
invalid escape error.
I’d only like to add I hope we can avoid HEREDOC strings are compared to
Brent’s continuation
approach as the aesthetics are not at all good.
> On 26 Apr 2016, at 07:04, Chris Lattner <[email protected]> wrote:
>
> On Apr 25, 2016, at 5:22 PM, Brent Royal-Gordon <[email protected]>
> wrote:
>>>> 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.
>>
>> Modifiers are definitely a workable alternative, and can be quite flexible,
>> particularly if a future macro system can let you create new modifiers.
>
> Right. I consider modifiers to be highly precedented in other languages, and
> therefore proven to work. If we go this way, I greatly prefer prefix to
> postfix modifiers.
>
>>>> * 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.
>>
>> On the other hand, the `"""` does form a much larger, more obvious
>> continuation indicator. It is *extremely* obvious that the above line is not
>> Swift code, but something else embedded in it. It's also extremely obvious
>> what its extent is: when you stop seeing `"""`, you're back to normal Swift
>> code.
>
> Right, but it is also heavy weight and ugly. In your previous email you said
> about the single quote approach: "The quotation marks on the left end up
> forming a column that marks the lines as special”, so I don’t see a need for
> a triple quote syntax to solve this specific problem.
>
>> I *really* don't like the idea of our only alternatives being "one
>> double-quote mark with backslashing" or "use an entire heredoc". Heredocs
>> have their place, but they are a *very* heavyweight quoting mechanism, and
>> relatively short strings with many double-quotes are pretty common.
>> (Consider, for instance, strings containing unparsed JSON.) I think we need
>> *some* alternative to double-quotes, either single-quotes (with the same
>> semantics, just as an alternative) or this kind of quote-stacking.
>
> I agree that this is a real problem that would be great to solve.
>
> If I step back and look at the string literal space we’re discussing, I feel
> like there are three options:
>
> 1) single and simple multiline strings, using “
> 2) your triple quote sort of string, specifically tuned to avoid having to
> escape “ when it occurs once or twice in sequence.
> 3) heredoc, which is a very general (but also very heavy weight) solution to
> quoting problems.
>
> I’m trying to eliminate the middle one, so we only have to have "two things”.
> Here are some alternative ways to solve the problem, which might have less
> of an impact on the language:
>
> A) Introduce single quoted string literals to avoid double quote problems
> specifically, e.g.: ‘look “here” I say!’. This is another form of #2 which
> is less ugly. It also doesn’t help you if you have both “ and ‘ in your
> string.
>
> B) Introduce a modifier character that requires a more complex closing
> sequence to close off the string, see C++ raw string literals for prior art
> on this approach. Perhaps something like:
>
> Rxxx”look “ here “ I can use quotes “xxx
>
> That said, I still prefer C) "ignore this issue for now”. In other words, I
> wouldn’t want to block progress on improving the string literal situation
> overall on this issue, because anything we do here is an further extension to
> a proposal that doesn’t solve this problem.
>
>>
>>> 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).
>>
>> There are two questions and a suggestion I have whenever heredoc syntax
>> comes up.
>>
>> Q1: Does the heredoc begin immediately, at the next line, or at the next
>> valid place for a statement to start? Heredocs traditionally take the second
>> approach.
>>
>> Q2: Do you permit heredocs to stack—that is, for a single line to specify
>> multiple heredocs?
>>
>> S: During the Perl 6 redesign, they decided to use the delimiter's
>> indentation to determine the base indentation for the heredoc:
>>
>> func x() -> String {
>> return <<EOF
>> <?xml version="1.0"?>
>> <catalog>
>> \t<book id="bk101" empty="">
>> \t\t<author>\(author)</author>
>> \t</book>
>> </catalog>
>> EOF
>> }
>>
>> Does that seem like a good approach?
>
> I think that either approach could work, that you have a lot more experience
> on these topics than I do, and I would expect a vigorous community debate
> about these topics. :-)
>
> That said, if you look at what we’re discussing:
>
> 1. “Continuation" string literals, to allow a multi-line string literal. You
> and I appear to completely agree about this.
> 2. Heredoc: You and I seem to agree that they are a good “fully general”
> solution to have, but there are the details you outline above to iron out.
> 3. Modifier characters: I’m in favor, but I don’t know where you stand.
> There is also still much to iron out here (such as the specific characters).
> 4. A way to avoid having to escape “ in a non-heredoc literal. I’m still
> unconvinced, and think that any solution to this problem will be orthogonal
> to the problems solved by 1-3 (and therefore can be added after getting
> experience with the other parts).
>
> If you agree that these are all orthogonal pieces, then treat them as such:
> I’d suggest that you provide a proposal that just tackles the continuation
> string literals. This seems simple, and possible to get in for Swift 3.
> After that, we can discuss heredoc and modifiers (if you think they’re a good
> solution) on their own threads. If those turn out to be uncontroversial,
> then perhaps they can get in too.
>
> On the heredoc aspects specifically, unless others chime in with strong
> opinions about the topics you brought up, I’d suggest that you craft a
> proposal for adding them with your preferred solution to these. You can
> mention the other answers (along with their tradeoffs and rationale for why
> you picked whatever you think is right) in the proposal, and we can help the
> community hash it out.
>
> What do you think?
>
> -Chris
>
>
>
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
