[swift-evolution] multi-line string literals.

Mon Apr 3 15:09:55 CDT 2017

Hi Pavel, you've misunderstood what I was saying. :)

I was focused specifically on the example Adrian posted a few messages up,
where he cited wanting something like Python's implicit concatenation when
a string is broken across multiple lines but each segment is still quoted;
as Ricardo pointed out, that's not a significant improvement over adding +
to the end of each line, and it's what I meant when I said doing the same
things two ways.

I'd be much more supportive of *true* multi-line strings or heredocs where
the newlines that are part of the string in the source code are also part
of the string—not just implicit concatenation around line breaks, but
retaining the structure of the string as well. That's not two ways to do
the same thing, since the latter isn't supported yet by Swift. So we're
probably in agreement.

That being said, while I can see the necessity, I'm actually not a fan of
large strings in the middle of source code for many of the reasons cited
already—I think it's a bit of a code smell to embed that much data in the
source, and editors can have difficulty handling it when the syntax
highlighting context changes to drastically. In my ideal world, I'd like a
way for me to import the contents of an external file as a String or a
binary blob so that it still gets brought into the data segment but it's
not a huge chunk of unrelated content in the middle of my logic.

That's a harder sell when you think of the Apple OS use cases because you
can just load data from bundled resources, but it might be more valuable in
server contexts, and if they could support interpolation as well, that
would be a powerful templating mechanism as well.

On Mon, Apr 3, 2017 at 11:44 AM Paweł Wojtkowiak <neframair at gmail.com>
wrote:

> I think that there's nothing wrong with two "tools" for the same task in
> this case. Multiline strings look better in the code and are easier to read
> and can serve many purposes. By reading different texts from swift dev team
> I feel like this is something the language was designed with in mind.
> They're also easier to type and it needn't neccessarily be a string
> presented to the user.
>
> Lets say I want a simple json literal for testing purposes - reading from
> a file takes much more effort comparing to inserting it directly in the
> code. Taking out every new line character makes it hard to read, and
> inserting quotes and pluses every line both needs extra effort and also
> decreases readability. Adding it as a multiline string would make a perfect
> solution for this to me.
>
> There are so many other cases where this could be useful too. I like how
> python has the """ and I think this would be a good direction to go,
> although this is true that python uses indentation in a different way, so I
> think backslashes at the end of each line would be a nice idea - this is
> still better than concatenating each line with " and +, and would have the
> least readability impact. Also, it could be treated as a literal and be
> evaluated at compile time.
>
> I just checked with -O and without and was surprised to find that `let x =
> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than
> it is in some other languages because of operator overloads and different
> kinds of text literals (strings, extended grapheme clusters, Unicode
> scalars)?
>
> Regardless of the reasons, a separate syntax isn't the right way to
> achieve this optimization—the compiler should just do it automatically.
> Like Ricardo, "multi-line string literals" should be reserved for string
> literals that include the newline characters that are used to break them up
> in source. The idea of supporting something like the Python example above
> just provides two ways to do the same thing, which I don't think we really
> need.
>
>
> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> I would think that the concatenation would get resolved at runtime, unless
> the compiler gets smart about it.  But either way I do not see it as a
> problem.  The reason is that I don't remember ever worrying about the
> performance of concatenating a few lines of text.  :-)
>
> Thanks
>
> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev <
> adrian.zubarev at devandartist.com> wrote:
>
> To me a literal a single entity which is solved at compile time. The
> concatenation is however resolved at runtime if I’m not mistaken here (it
> might be optimized at compile time but I still would expect a function
> executed a couple of times at runtime).
>
> Please correct me if I’m wrong here.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 17:10:36, Ricardo Parada (rparada at mac.com) schrieb:
>
> How is that better than this?
>
> template = "This is the first line.\n" +
>             "This is the second line.\n" +
>             "This is the third line."
>
>
> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> It look prettier without the \n
>
> It's not laziness.
>
> I want my code to look pretty.
>
>
> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev <
> adrian.zubarev at devandartist.com> wrote:
>
> What I was trying to say is that by automatically adding a new line
> character does not provide any benefit except of being lazy to type \n.
>
> // In your model this would be equivalent
> let s1 = "\n\n\n"
> let s2 = """
>     " // However in my model this is an empty string and should be banned
>     "
>     """ // That's also an empty string, but it that case it indicates the end of the multi lined string
>
> I dislike the tradeoff of precision for laziness.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 16:29:44, Ricardo Parada (rparada at mac.com) schrieb:
>
> By the way, the multi-line string should allow \n\n, or as many as you may
> want to throw in there.  I don't see a problem with that.
>
>
>
> _______________________________________________
> 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/20170403/1928dca7/attachment.html>