[swift-evolution] multi-line string literals

[David Owens II]

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:

The position of the opening """ dictates the left-edge for indentation purposes.
It’s invalid to have any text on the lines that contain the start and stop tokens: """
The start and stop tokens must be left-edge aligned.
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 <mailto:jason.dusek at gmail.com>> wrote:
> On Thu, 10 Dec 2015 at 21:45, Travis Tilley via swift-evolution <swift-evolution at swift.org <mailto: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:
> 
> The indentation level is set from the least indented line that is not the first line and is not empty.
> A leading empty line is removed.
> 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/4b5c4b2c/attachment.html>