[swift-evolution] multi-line string literals

[Jason Dusek]

But I think str3 is what most of us want most of the time -- so why do we
have to pass options for it? Let the unusual cases have options.

On Thu, 10 Dec 2015 at 22:46 Jacob Bandes-Storch <jtbandes at gmail.com> wrote:

> 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/20151211/1edba847/attachment.html>