[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