[swift-evolution] multi-line string literals

[Marc Knaup]

Speaking of line endings…

"""
Line1
Line2
Line3
"""

On Mac/Unix the lines in the source file would likely end in \n while on
Windows the would likely end in \r\n.
What line endings would the resulting string have? The one from the source
file or would it be normalized to \n?

On Fri, Dec 11, 2015 at 11:31 PM, Travis Tilley via swift-evolution <
swift-evolution at swift.org> 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.
>
> ​
>
>
> On Fri, Dec 11, 2015 at 5:10 PM, Brent Royal-Gordon <
> brent at architechies.com> wrote:
>
>> > I would very much like to implement multi-line string literals in swift
>> and get feedback on what this should look like, as i've been informed there
>> are several competing suggestions filed as radars.
>>
>> Some principles:
>>
>> 1. You do not want to plop enormous multi-line string constants in the
>> middle of expressions. This makes the expressions impossible to read.
>> Instead, you want a placeholder for the string in the expression, and then
>> the string on a separate line.
>>
>> 2. Having said that, when there are several placeholders, you also want
>> it to be obvious which text goes with which placeholder.
>>
>> 3. You want a syntax which clearly indicates which indentation is meant
>> to line up the string literal with the code, and which is meant to be *in*
>> the string literal.
>>
>> With these principles in mind, I suggest something like:
>>
>>         onMessage(DAVE>, sendMessage: HAL>)
>>         DAVE>Open the pod bay doors,
>>         DAVE>   HAL!
>>         HAL>I’m sorry, Dave,
>>         HAL>    I’m afraid I can’t
>>         HAL>    do that.
>>
>> A multiline literal reference consists of an identifier followed by a
>> closing angle bracket in postfix operator position. After the end of any
>> statement containing a multiline literal reference, Swift starts looking
>> for the actual multiline literals mentioned in that statement. Leading
>> whitespace is consumed and discarded up to a matching identifier and angle
>> bracket; the text on the line after the literal, up to the newline, is the
>> text of the literal. Once Swift encounters a line that doesn’t start with
>> whitespace, an identifier, and an angle bracket, it switches back to
>> looking for ordinary statements.
>>
>> (By the way, the all-caps is a stylistic suggestion, not a requirement,
>> and I’m not at all sure it’s the *right* stylistic suggestion.)
>>
>> As a shorthand for lines with only one string, you might be able to say:
>>
>>         sendMessage(_>)
>>         >I’m sorry, Dave,
>>         >       I’m afraid I can’t
>>         >       do that.
>>
>> While this solves the indentation problem, it doesn’t answer the question
>> of whether the trailing \n is part of the literal. I think it is. I’m
>> actually tempted to say that *all* newlines are ignored and you need \n if
>> you want a real newline, but that seems like it would do a lot of violence
>> to the entire concept of a multiline literal.
>>
>> --
>> 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/20151211/fabdb8aa/attachment.html>