[swift-evolution] multi-line string literals.
Matthew Johnson
matthew at anandabits.com
Thu May 5 21:13:33 CDT 2016
> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>>> On 5 May 2016, at 14:17, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>>>
>>>
>>>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>
>>>> it's not a secret that I'm not a big fan of the proposal. The third draft doesn't change this and it's unlikely that any future draft will, because for me, the problem are the continuation quotes, and for Brent it seems like they are a must-have-feature (correct me if I'm wrong.)
>>>
>>> I agree with all you said. I’m fairly sure I would never vote for Brent’s proposal simply because of the existence of continuation quotes, no matter the amount of reasoning behind it. They are simply too unwieldy, cumbersome and unfriendly to modification.
>>>
>>> I could see either your proposal, or your proposal without the HERE_DOCs but using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal proposal?
>>
>>
>> Adapting the original proposal if you’re not a fan of continuation quotes..
>>
>> It’s possible to have a multiline “””python””” multi-line string but tidily indented.
>> As suggested earlier in this thread the lexer can strip the margin on the basis of
>> the whitespace before the closing quote as per Perl6 (This could be a modifier “I”
>> but might as well be the default TBH.) Would this be the best of both worlds?
>>
>> assert( xml == i"""
>> <?xml version="1.0"?>
>> <catalog>
>> <book id="bk101" empty="">
>> <author>\(author)</author>
>> <title>XML Developer's Guide</title>
>> <genre>Computer</genre>
>> <price>44.95</price>
>> <publish_date>2000-10-01</publish_date>
>> <description>An in-depth look at creating applications with XML.</description>
>> </book>
>> </catalog>
>> ""” )
>>
>> Other modifiers can also be applied such as “no-escapes"
>>
>> assert( xml != ei"""<?xml version="1.0"?>
>> <catalog>
>> <book id="bk101" empty="">
>> <author>\(author)</author>
>> <title>XML Developer's Guide</title>
>> <genre>Computer</genre>
>> <price>44.95</price>
>> <publish_date>2000-10-01</publish_date>
>> <description>An in-depth look at creating applications with XML.</description>
>> </book>
>> </catalog>
>> """ )
>>
>> I’d hope this would satisfy any need for <<HERE/<<‘HERE’ style constructs.
>>
>> Or you could support both continuation and indented python style:
>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz <http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz>
>>
>> John
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I’m of the opinion that either of these are reasonable solutions, and both offer different tradeoffs. I’m probably partial to the continuation quotes, because I don’t want to be guessing about what is going to end up being in my string and what won’t.
>
>> assert( xml != ei"""<?xml version="1.0"?>
>> <catalog>
>> <book id="bk101" empty="">
>> <author>\(author)</author>
>> <title>XML Developer's Guide</title>
>> <genre>Computer</genre>
>> <price>44.95</price>
>> <publish_date>2000-10-01</publish_date>
>> <description>An in-depth look at creating applications with XML.</description>
>> </book>
>> </catalog>
>> ""” )
>
> For example, is there a new line after </catalog>?
> How would the indenting work if it were immediately followed by triple quotes: </catalog>”””
> I would really like the first line to be lined up with the rest of the xml. Is that going to introduce a newline into the top of the string?
>
> Could we just enforce that no characters on the lines of the triple quotes would be included in the string, very much like the heredoc syntax?
>
> assert( xml != ei"”” The text I’m typing here would cause a compiler error.
> <?xml version="1.0"?>
> <catalog>
> <book id="bk101" empty="">
> <author>\(author)</author>
> <title>XML Developer's Guide</title>
> <genre>Computer</genre>
> <price>44.95</price>
> <publish_date>2000-10-01</publish_date>
> <description>An in-depth look at creating applications with XML.</description>
> </book>
> </catalog>
> same here ""” )
>
> Then it’s very clear what the whitespace stripping will do. But what about mixed tab vs whitespace? What is the behavior in that case?
I’m jumping into this thread late and have only followed bits of it so I apologize if I’m repeating anything.
I really like the idea of having leading space stripped automatically without requiring the continuation quotes. I have done my share of leading space stripping in the past when working with heredocs. It’s not that big a deal but it would be better to have the language take care of it for us.
I like the idea of banning any characters on the same line as the triple quotes (not just omitting them but actually making it a syntax error to include them).
As far as mixed whitespace, I think the only sane thing to do would be to only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading whitespace would be a syntax error. All lines in the string would need to use tabs or all lines use spaces, you could not have one line with tabs and another with spaces. This would keep the compiler out of the business of making any assumptions or guesses, would not be a problem often, and would be very easy to fix if it ever happens accidentally.
-Matthew
>
> Tyler
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160505/e74bc572/attachment.html>
More information about the swift-evolution
mailing list