<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">I'm not entirely sure how to respond to this, but I think some of your suggestions might go against the goal of having less noise in defining a multi-line string. It's actually more to type than:</div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">"this is the first line \n" +<br>"this is the second line \n"</blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">...which we can already do.</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">Your suggestion that each line should end in \n makes me think you're actually trying to have a bit of fun with me, but I can't really tell and I really don't want to be rude by making that assumption.</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"></div> </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 5:10 PM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I would very much like to implement multi-line string literals in swift and get feedback on what this should look like, as i've been informed there are several competing suggestions filed as radars.<br>
<br>
</span>Some principles:<br>
<br>
1. You do not want to plop enormous multi-line string constants in the middle of expressions. This makes the expressions impossible to read. Instead, you want a placeholder for the string in the expression, and then the string on a separate line.<br>
<br>
2. Having said that, when there are several placeholders, you also want it to be obvious which text goes with which placeholder.<br>
<br>
3. You want a syntax which clearly indicates which indentation is meant to line up the string literal with the code, and which is meant to be *in* the string literal.<br>
<br>
With these principles in mind, I suggest something like:<br>
<br>
onMessage(DAVE>, sendMessage: HAL>)<br>
DAVE>Open the pod bay doors,<br>
DAVE> HAL!<br>
HAL>I’m sorry, Dave,<br>
HAL> I’m afraid I can’t<br>
HAL> do that.<br>
<br>
A multiline literal reference consists of an identifier followed by a closing angle bracket in postfix operator position. After the end of any statement containing a multiline literal reference, Swift starts looking for the actual multiline literals mentioned in that statement. Leading whitespace is consumed and discarded up to a matching identifier and angle bracket; the text on the line after the literal, up to the newline, is the text of the literal. Once Swift encounters a line that doesn’t start with whitespace, an identifier, and an angle bracket, it switches back to looking for ordinary statements.<br>
<br>
(By the way, the all-caps is a stylistic suggestion, not a requirement, and I’m not at all sure it’s the *right* stylistic suggestion.)<br>
<br>
As a shorthand for lines with only one string, you might be able to say:<br>
<br>
sendMessage(_>)<br>
>I’m sorry, Dave,<br>
> I’m afraid I can’t<br>
> do that.<br>
<br>
While this solves the indentation problem, it doesn’t answer the question of whether the trailing \n is part of the literal. I think it is. I’m actually tempted to say that *all* newlines are ignored and you need \n if you want a real newline, but that seems like it would do a lot of violence to the entire concept of a multiline literal.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br></font></span></blockquote></div>
</div></div>