<html><head><style>
body {
        font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
        padding:1em;
        margin:auto;
        background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
        font-weight: bold;
}
h1 {
        color: #000000;
        font-size: 28pt;
}
h2 {
        border-bottom: 1px solid #CCCCCC;
        color: #000000;
        font-size: 24px;
}
h3 {
        font-size: 18px;
}
h4 {
        font-size: 16px;
}
h5 {
        font-size: 14px;
}
h6 {
        color: #777777;
        background-color: inherit;
        font-size: 14px;
}
hr {
        height: 0.2em;
        border: 0;
        color: #CCCCCC;
        background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
        margin: 15px 0;
}
a, a:visited {
        color: #4183C4;
        background-color: inherit;
        text-decoration: none;
}
#message {
        border-radius: 6px;
        border: 1px solid #ccc;
        display:block;
        width:100%;
        height:60px;
        margin:6px 0px;
}
button, #ws {
        font-size: 12 pt;
        padding: 4px 6px;
        border-radius: 5px;
        border: 1px solid #bbb;
        background-color: #eee;
}
code, pre, #ws, #message {
        font-family: Monaco;
        font-size: 10pt;
        border-radius: 3px;
        background-color: #F8F8F8;
        color: inherit;
}
code {
        border: 1px solid #EAEAEA;
        margin: 0 2px;
        padding: 0 5px;
}
pre {
        border: 1px solid #CCCCCC;
        overflow: auto;
        padding: 4px 8px;
}
pre > code {
        border: 0;
        margin: 0;
        padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>I think it would be good to clarify that there are two similar things we discuss in this proposal.</p>
<ol>
<li><p>This proposal is about a [(multi-line string) literal].</p></li>
<li><p>And there is also the [multi-line (string literal)].</p></li>
</ol>
<p>These are two different things because (1) does add explicit escaping for some characters, where (2) is the current string literal extended for multilines.</p>
<p>As I already mentioned in my previous post, personally I’m in favor of (2) and the existence of (2) raises the question if we need (1) for implicit escaping at all, which I personally like to compare with laziness.</p>
<p>The existence of (2) is easier from the writers perspective, because if you decide at some point to break up your string into multi lines, the string itself won’t be altered because there is no implicit character added to the string, and indent would work as you’d expect it to work. If one would need more precision there would exist leading and trailing precision characters. </p>
<p>However, I think it might be really good compromise, at least to me, as someone mentioned in this review, that we could add a backslash to the proposed (1) [(multi-line string) literal] to prevent implicit new lines and at the same time add trailing precision.</p>
<p>Final words, if I had to choose between (1) and (2), I’d go with (2), because I don’t like the optimization magic that happens behind the scene and would prefer a concrete model for a string literal.</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1491820270855400192" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 10. April 2017 um 04:44:15, Brent Royal-Gordon via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
<div>
<blockquote type="cite" class="">
<div class="">On Apr 9, 2017, at 9:29 AM, John Holdsworth via
swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
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.</div>
</div>
</blockquote>
<br class=""></div>
<div>Honestly, I think this is a little premature. If I had to
summarize this thread, I think what I'm seeing is:</div>
<div><br class=""></div>
<div>1. We wish the proposal were more specific on a few points,
like the de-indenting algorithm.</div>
<div><br class=""></div>
<div>2. We have lots of different pet syntaxes and
preferences.</div>
<div><br class=""></div>
<div>3. But most of us are still in favor of accepting the
proposal.</div>
<div><br class=""></div>
<div>To back up that last point, I ran through the thread and tried
to quickly figure out what everyone was thinking. These people seem
to be opposed to the proposal: </div>
<div class=""><br class=""></div>
<div class="">1. Haravikk doesn't like the de-indenting and seems
iffy on multiline strings in general.</div>
<div class="">2. David Waite wants a suite of different, orthogonal
string literal features to get enough flexibility.</div>
<div class="">3. Félix Cloutier is worried that supporting
interpolation makes this feature a powerful footgun.</div>
<div class="">4. Adrian Zubarev wants to extend single-quoted
string literals instead of developing a second syntax.</div>
<div class=""><br class=""></div>
<div class="">
<div class="">These people want the proposal to be more specific,
but appear to be in favor as long as the missing details don't
reveal problems:</div>
<div class=""><br class=""></div>
<div class="">1. Greg Parker (maybe?)</div>
<div class="">2. Xiaodi Wu</div>
<div class="">3. Gwendel Roué</div>
</div>
<div class=""><br class=""></div>
<div class="">And these people all seem basically positive, though
sometimes with reservations or bikeshedding suggestions:</div>
<div class=""><br class=""></div>
<div class="">1. Me</div>
<div class="">2. Tony Allevato</div>
<div class="">3. David Hart</div>
<div class="">4. Daniel Duan</div>
<div class="">5. Ricardo Parada</div>
<div class="">6. Kevin Nattinger</div>
<div class="">7. Víctor Pimentel Rodríguez</div>
<div class="">8. Jarod Long (I think)</div>
<div class="">9. Ben Cohen</div>
<div class="">10. Thorsten Seitz</div>
<div class="">11. Howard Lovatt</div>
<div class="">12. T.J. Usiyan</div>
<div class=""><br class=""></div>
<div class="">Evolution reviews are not referenda, but I think it's
fair to say that the sentiment is mostly positive.</div>
<div class=""><br class=""></div>
<div class="">(And if the core team does say they like the approach
but want clarifications, I'd be happy to pitch in and earn the
co-author credit!)</div>
<br class="">
<div class="">
<div class="">
<div style="font-size: 12px;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;">
-- </span></div>
<div style="font-size: 12px;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;">
Brent Royal-Gordon</span></div>
<div style="font-size: 12px;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;">
Architechies</span></div>
</div>
</div>
<br class="">
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>