[swift-evolution] multi-line string literals

[Kametrixom Tikara]

Whops sorry I got the symbols mixed up, Swift's macro system uses "%", but the preprocessor uses "#". By using "#" as a delimiter, the lexer would have to be adjusted quite a bit to work for both literals and the preprocessor.

> On 12 Dec 2015, at 02:09, Kametrixom Tikara via swift-evolution <swift-evolution at swift.org> wrote:
> 
> This would probably conflict with Swift's non-official (hopefully official in the future) macro-system (the .gyb files), which makes heavy use of "#".
> 
>> On 12 Dec 2015, at 01:13, Marc Knaup via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> What about #?
>> 
>> ###
>> string
>> ###
>> 
>> If your string does contain "###" you can simply guard the string with more # until it fits. Must be symmetrical though. No escaping necessary.
>> 
>>> On Sat, Dec 12, 2015 at 1:08 AM, Travis Tilley via swift-evolution <swift-evolution at swift.org> wrote:
>>> Ah. My sincerest apologies for making that assumption then.
>>> 
>>> Your suggestion doesn't solve my use case, personally. I'm also hoping to officially propose something less complex than heredocs once there's been enough feedback.
>>> 
>>> 
>>> -Travis Tilley
>>> 
>>> 
>>>> On Fri, Dec 11, 2015 at 5:52 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>>> > I'm not entirely sure how to respond to this, but I think some of your suggestions might go against the goal of having less noise in defining a multi-line string. It's actually more to type than:
>>>> > "this is the first line \n" +
>>>> > "this is the second line \n"
>>>> > ​...which we can already do.
>>>> >
>>>> > Your suggestion that each line should end in \n makes me think you're actually trying to have a bit of fun with me, but I can't really tell and I really don't want to be rude by making that assumption.
>>>> 
>>>> I am being serious. This proposal does require more characters, it’s true. However, it doesn’t require more *reading*—because the leading indicators will generally line up, you can ignore them and read everything to the right, like the “> “ used to demarcate your text above from my text—and with an editor feature to select several lines and quote them (the way you can with comments in most editors), it wouldn’t require more *writing* either. And although it uses more characters, it *also* unmistakably sets off quoted material from code, comments, other multiline string literals, and anything else, while being unambiguous about whether indentation is intended to style the literal or be part of it, without a bunch of funky obscure modifier characters like "<<-END".
>>>> 
>>>> The \n thing was an idle thought being presented for discussion, not a concrete suggestion, but it was also not a joke. (I realized after sending it, however, that the trailing newline problem can be solved by simply having a rule that you strip one trailing newline. If you want your string to end with a newline, include a sacrificial blank “Foo>” line at the end of the literal. Some sort of modifier to indicate the trailing newline behavior is possible too, but see the previous paragraph for my thoughts on those.)
>>>> 
>>>> I’ve used and loved heredocs in Perl and Ruby, but I always understood that they have significant problems. That experience shaped this proposal.
>>>> 
>>>> --
>>>> Brent Royal-Gordon
>>>> Architechies
>>>  
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20151212/0b7c2a9d/attachment.html>