[swift-evolution] multi-line string literals

[Marc Knaup]

This example will break easily when tabs are used for indentation or when
using refactoring tools to rename the variable:

let text = """
           This is ok.

           """

Rather I'd suggest that when there is no newline before the opening
triple-quote then the indentation is ignored completely, like in the
example from Drew Crawford:

let sampleJSON = """
{
  "foo": "bar",
  "baz": "bap\nbap"
}
"""

This is great for cases where you don't need to care about indentation or
where you want to copy&paste something without re-indenting it.
It also works fine no matter if the developer uses tabs or spaces for
indentation.

On Fri, Dec 11, 2015 at 10:26 AM, David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:

> I think I’d rather treat the multiline literal as a fenced block.
>
> let text =
>     """
>     The position of the first " is where the indentation is considered
> the left-edge.
>
>         This line is indented four spaces.
>
>
>
>
>     If I want a newline at the end of the string, I simply put one.
>
>     """
>
> This creates very easy rules to understand:
>
>
>    1. The position of the opening """ dictates the left-edge for
>    indentation purposes.
>    2. It’s invalid to have any text on the lines that contain the start
>    and stop tokens: """
>    3. The start and stop tokens must be left-edge aligned.
>    4. Text cannot be in a column that preceding the column the tokens
>    start on, unless it is only whitespace.
>
>
> More examples:
>
> let text =
>     """ Invalid: This is not allowed.
>     """
>
> let text = """ Invalid; edges are not aligned.
>
>     """
>
> let text = """
>     Invalid: Text cannot start before the """ tokens.
>
>            """
>
> let text = """
>            This is ok.
>
>            """
>
> let text = """
>            Escaped characters are interpreted as normal: \n\n
>            There will be two newlines above this string when rendered.
>
>            """
>
> -David
>
> On Dec 10, 2015, at 10:33 PM, Travis Tilley via swift-evolution <
> swift-evolution at swift.org> 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
>
>
>
> _______________________________________________
> 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/de54869a/attachment.html>