[swift-evolution] multi-line string literals.

[Chris Blessing]

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 at 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  <rainer at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution