Hi swift-evo, Forgive my naive interjection here. I’ve enjoyed lurking on this list and watching all the discussions around topics I don’t even fully understand, but this one strikes me.
I certainly agree that multi-line literals should be undistorted, and I also agree that they should be 100% easy to edit/read in the source. To that end, my (hold your breath) PHP dev days made great use of the heredoc syntax. I know it has been covered in this thread but I haven’t seen any compelling reason why it shouldn’t be the solution to this wanted feature. var myString = <<<SOMETAG // string content starts here after the new line SOMETAG>>> // ends here String interpolation could be implemented as-is: var myString = <<<LETTER Dear \(receipientName), I’m writing this letter to you… // more lines // more lines // more lines Sincerely, \(senderName) LETTER>>> There are a few constraints from PHP land which might make this easier (? simpler?) to implement: - multi-line string contents begin on the NEXT line after the opening heredoc operator - closing operator MUST have no prefix characters (so it must be directly after the last line of the string, and cannot be indented) —> this means source code formatting can be a tad out of alignment with the rest of your code but then what multi-line string isn’t? -> in fact the behavior is very similar to a <pre></pre> block of HTML, whitespace counts! Benefits include: - absolutely no need for a line-by-line delimiter - any character could be supported in the multi-line block - string interpolation is completely possible (and could be made optional if that speeds things up) - parser errors would be pretty simple to read and should be sufficient to prevent compile-time errors Again apologies if this has already been shot down, and yes I fully admit that I don’t even know the origin of heredoc syntax (it’s probably something awful or great from the past) but objectively, I can’t see too many downsides to this solution. With humility, -Chris > On May 2, 2016, at 7:47 AM, Rainer Brockerhoff via swift-evolution > <swift-evolution@swift.org> wrote: > > On 5/2/16 09:53, Brent Royal-Gordon via swift-evolution wrote: >> When you are embedding enormous string literals in source code, you >> must put undistorted representation of the string above all other >> considerations. If the design which best permits the string to be >> written verbatim is ugly, bulky, unlike other language constructs, >> disruptive to code readability, error-prone, arbitrary, difficult to >> parse, or otherwise a wart on the language, that is simply the price we >> have to pay for that feature. > > +1. I've tried to write this up a few times, but couldn't find a > satisfactory syntax; still, how about introducing "named comments" or > "footnotes in comments" like this: > > /*#label# > ...N lines of unescaped, as-is text > #*/ > > and elsewhere in source referring to this with some #construct(label) > syntax? > >> But it's a different story for short multiline strings. When you are >> writing a little bit of text, but still more than one line, you don't >> want to disrupt your code's indentation, add whole lines just for >> delimiters, insert bizarre or cryptic tokens into your code, or create >> syntax errors which take ten minutes to trace back to their source. You >> want a different feature, with different tradeoffs. > > At least for Xcode having a "paste as escaped string" would solve this, > other platforms/editors could have a standard macro with the same > effect. Of course readability of the pasted literal would suffer. > > > -- > Rainer Brockerhoff <rai...@brockerhoff.net> > Belo Horizonte, Brazil > "In the affairs of others even fools are wise > In their own business even sages err." > http://brockerhoff.net/blog/ > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
