[swift-evolution] multi-line string literals

[Jacob Bandes-Storch]

Just a thought: what about something more generalized & explicit, like a
MultilineLiteral type (a.k.a. StaticString), and a String initializer with
parameters for the options:

String.init(removeLeadingNewline: Bool = false, removeIndentation: Bool =
false, _ mulitilineLiteral: MultilineLiteral)

let str = """
   raw string; nothing changed
"""

let str2 = String(removeLeadingNewline: true, """
    leading newline is removed, but indentation remains
""")

let str3 = String(removeIndentation: true, """
    leading newline remains, but as much indentation as possible is removed
""")


(I'm not a fan of the trailing close-paren, but can't really think of a way
around it. Maybe an exception like trailing-closure syntax for
trailing-multiline-literals?)

Jacob

On Thu, Dec 10, 2015 at 10:38 PM, Jason Dusek via swift-evolution <
swift-evolution at swift.org> wrote:

> Yeah, I can't say I am totally committed to the fourth one.
>
> On Thu, 10 Dec 2015 at 22:34 Travis Tilley <ttilley at gmail.com> wrote:
>
>> I had been operating on the assumption that a leading blank line would be
>> stripped if present, since the syntax in code would look much cleaner, but
>> a trailing line would not since it would likely be intentional. I guess
>> that's another detail that would need to be fleshed out if we decide to go
>> with triple quote syntax (which, at this point, isn't a given... chris
>> lattner brings up some very good points that might require more involved,
>> potentially heredoc-like, syntax to solve).
>>
>> Your fourth rule, however, I don't agree with at all. It should be
>> obvious from where you place the final quotes whether or not the string
>> includes a trailing newline. Just like in ruby, I believe in and value the
>> principle of least surprize.
>>
>>
>> - Travis Tilley
>>
>>
>> On Fri, Dec 11, 2015 at 1:04 AM, Jason Dusek <jason.dusek at gmail.com>
>> wrote:
>>
>>> On Thu, 10 Dec 2015 at 21:45, Travis Tilley via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> The ruby <<- heredoc syntax, unlike the << heredoc syntax, will strip
>>>> indentation if necessary. Technically, it searches for the "least indented
>>>> line" in the whole string, and removes exactly that amount from each line.
>>>> So yes, the indentation problem -is- solved in ruby (though it might break
>>>> entirely if you have empty lines, since the least indented line has no
>>>> indentation).
>>>>
>>> To my mind, the rules should be:
>>>
>>>    1. The indentation level is set from the least indented line that is
>>>    not the first line and is not empty.
>>>    2. A leading empty line is removed.
>>>    3. The leading line, if there is any text in it, is not subject to
>>>    de-indentation.
>>>
>>> I genuinely believe these three rules taken together address all the
>>> errors and infelicities to which triple quotes and HEREDOCs subject us.
>>> Here are some examples:
>>>
>>> text = """
>>>     Some
>>>
>>>   Features
>>>     Are
>>>     Discussed
>>> """# From (1): The indentation is taken from the third line below `text`, so it's 2.# From (2): First line is: "\n" so it is removed.# From (3): No effect.
>>>
>>> text = """  Some
>>>
>>>           Features
>>>             Are
>>>             Discussed
>>> """# From (1): The indentation is taken again from the line reading "Features". Here it is 10.# From (2): No effect.# From (3): The leading whitespace in `  Some` is preserved.
>>>
>>> Do you all think these rules pass muster?
>>>
>>> A fourth rule — one which seems advisable but also less necessary than
>>> the others — is that a string constructed in this way always ends with a
>>> newline. It is a rule that perhaps leads to surprises and inconsistencies.
>>>
>>> Best Regards,
>>>
>>> Jason
>>> ​
>>>
>>
> _______________________________________________
> 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/20151210/93351681/attachment.html>