[swift-evolution] multi-line string literals.

[Nick Keets]

To me the discussion about precision of multiline strings is missing the
point. The biggest use case of this would be when using swift in a more
script-like fashion. You just paste something, add a
.components(separatedBy: “\n”).map { something() } and you print the result.

If you need precision, localizations, etc, multiline strings don’t have too
much to offer. You could just use plain + with marginal overhead. Or use
resource files.

On Mon, Apr 3, 2017 at 11:18 PM, Ricardo Parada via swift-evolution <
swift-evolution at swift.org> wrote:

> Why would backslashes at the end of each line be a nice idea?
>
> Sent from my iPhone
>
> On Apr 3, 2017, at 2:44 PM, Paweł Wojtkowiak via swift-evolution <
> swift-evolution at swift.org> 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
>>
> _______________________________________________
> 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/20170404/0350e689/attachment.html>