[swift-evolution] [Review] SE-0168: Multi-Line String Literals

Kevin Nattinger swift at nattinger.net
Sun Apr 9 18:29:04 CDT 2017


> On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a “feature" but I can see it would be too magical for some. To specify it more you could say: if there is only whitespace between the last newline and the end of a multiline literal this whitespace will be stripped from all lines in the literal. If lines do not start with this exact sequence of whitespace a warning is emitted. In addition, if the first character in the literal is a newline it will be removed. This operation could be made explicit e.g. #trimLeft(“”"a literal"”")

Yeah, that was my one hesitation. I actually didn’t understand the scheme at first and thought *all* whitespace would be left-trimmed. What about just adding a `leftTrimLines()` or `deindent()`+`deindent(levels:Int)` or comparable string method, so you could just do something like this:

let json = """
    {
        "a": "b",
        "c": {
            "d": 3
        }
    }
""".deindent()

As a bonus, you can use this for non-literals should the need arise.

> 
> Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.

I’d really rather just see the core team accept this with a modification to trimming, otherwise I guarantee it’s not getting in this year.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170409/2295cd42/attachment.html>


More information about the swift-evolution mailing list