[swift-evolution] multi-line string literals

Marc Knaup marc at knaup.koeln
Fri Dec 11 18:13:29 CST 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/efdba5cf/attachment.html>


More information about the swift-evolution mailing list