World War String

Swift Evolution is engaged in a war over the multi-line string. While this conversation dates back some time, it has progressively grown more heated in recent days.

I just want closure. I’m more interested in closure than perfection. My favorite solution to date is the Holdsworth/Royal-Gordon approach:


It is simple. It does not disallow pasted text, with the proper support from Xcode. It can theoretically be applied (and removed) mechanically as you can currently do with commenting.

Its parsing/lexing is simple and already Holdsworthed. (In theory, everything that can be conceptualized in Xcode is nearly Holdsworthed.) And it probably wouldn’t be hard to request an Xcode modification similar to Comment/Uncomment that indents and inserts quotes and toggles back to left-alignment at the initial quote mark.

That the debate rages on remains a mystery to me.

Speaking of Xcode and its commenting support, I am still waiting for better Apple-originated structured documentation commenting. As is, it’s particularly ridiculous to try to introduce sample code blocks without manually spacing and adding in third slashes, let alone proof for spell checking and grammar. But that’s probably a rant better left for another blog post.

For today, I support the Holdsworth/Royal-Gordonians. Viva la quoted resistance!


  • Actually, it doesn’t allow pasted text because of the leading quotes in each row. Until Xcode gets multiple cursor support, this means you have to open another editor. Not ideal.

    • The Apple folk have said they can make things happen along the toolchain. This format does not disallow pasted text and the the quotes could theoretically be indented and applied (and removed) mechanically.

      I will update the text because I did not make my point clearly.

    • You’d have to paste it and then do a find/replace of the beginning of each line with “, the equivalent of `a,bs/^/”/` in vi where a and b are line numbers. However, Xcode can easily be changed to have a command that will do this for you, similar to the way `cmd`+`/` prefixes every line in the selection with `//`.

      My feeling is that we need one way (and one way only, not like Perl) of doing this. I think Chris Lattner should just impose his own personal preference and have done with it. The total amount of energy expended on this so far has probably exceeded the amount needed to implement the solution.

      • Just to be clear, I don’t care what solution is chosen as long as one single solution is chose,

  • I’m on the other side of the fence. Swift is now multiplatform, and will be used with other editors than Xcode, and not all have great multi cursor support. And even with multi-cursor support, adding and removing line breaks is not as easy as with the other approach.

  • I like it. I’ve always preferred a line-break style that shows the broken line at the *start* of the line rather than the end. So I even do long conditionals like this (Not sure if this formatting is going to work..)

    if ( thisIsALongConditional()
    && thisIsStillALongConditional()
    && whenWillThisMadnessStop())

    I like it because it shows me the purpose of the line I’m reading. When I see the && (or whatever) then it’s clear that this line is continuing from the above.

    This is as opposed to

    if (thisIsALongConditional() &&
    thisIsStillALongConditional() &&

  • Just to be clear.. all that vertical whitespace should be there.. dunno why the HTML code tag does that. But there you have it.