<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"><ul>
<li><p>What is your evaluation of the proposal?</p>

<p>–1 for the proposed solution, but in general I’d myself would want to see multi-line strings in Swift. The current proposal does not cover precision, which could also be desired by developers.</p>

<p>My _personal_ view on how I wish multi-line strings do behave is actually similar to the magical string concatenation which is an optimization during compile time (not included in Xcode 8.3). Many people disagree with this point of view in favor of implicit new lines and non escaped <code>"</code> character, which is fine by me only if we can extend the standard string literal to support multilines too. Such extension will be stricter and have special precision rules.</p></li>
</ul>

<pre><code class="swift">// Simplicity which supports indent but at a cost of no    
// leading or trailing space characters
let string1 = "my
        multiline
        string"

print(string1) // prints "mymultilinestring"

let string2 = "my \    
        multiline \
        string"
           
// Trailing precision
print(string2) // prints "my multiline string"

let string3 = "my
        " multiline
        " string"
           
// Leading precision
print(string3) // prints "my multiline string"

let string4 = "my \
        " multiline \
        " string"
           
// Leading and trailing precision
print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)

let string5 = "my\
        "multiline\
        "string"
           
// Leading and trailing precision
// Provide a fix-it to remove some `\` and `"` characters
// because it equals `string1`
print(string5) // prints "mymultilinestring"

let string6 = "my \
        "multiline \
        "string"
           
// Leading and trailing precision
// Provide a fix-it to remove some `"` characters
// because it equals `string2`
print(string6) // prints "my multiline string"

let string7 = "my\
        " multiline\
        " string"
           
// Leading and trailing precision
// Provide a fix-it to remove some `\` characters
// because it equals `string3`
print(string7) // prints "my multiline string"
</code></pre>

<p>Additionally you can support a similar version of multilines strings with <code>"""</code> notation for those of use who are lazy to type <code>\n</code> and <code>\"</code> and want implicit new lines. However this raises the question, if the addition of <code>"""</code> is warrant it’s existence only for laziness and copy pasting? </p>

<p>The above example should also support string interpolation.</p>

<ul>
<li><p>Is the problem being addressed significant enough to warrant a change to Swift?</p>

<p>Not enough from my point of view.</p></li>
<li><p>Does this proposal fit well with the feel and direction of Swift?</p>

<p>The addition of multi-lined strings does fit, however I don’t think the proposed solution satisfies everyone. Personally I’d probably never use a multi-lined string as proposed, just because it adds implicit new lines to my very long string, which I maybe only want to break up into a few lines for better readability without the boilerplate of the not so obvious optimization magic provided by the complier though the concatenation operator <code>+</code>.</p>

<p>I think the correct name is *multi line string literal*, which is different from _multi line string_. The former should not have any implicit behavior except if there are two different versions like <code>"__"</code> and <code>"""___"""</code>. </p></li>
<li><p>If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</p>

<p>Javascript has this nice ability to break up strings into multilines with trailing precision, which I used in the example above.</p></li>
<li><p>How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p>

<p>Read the whole proposal and took part in latest discussion thread.</p></li>
</ul>

<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_1491647277470134016" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">--&nbsp;<br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 6. April 2017 um 21:35:50, Joe Groff 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>


Hello Swift community,<br class="">
<br class="">
The review of SE-0168 "Multi-Line String Literals" begins now and
runs through April 12, 2017. The proposal is available
here:<br class="">
<br class="">
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md</a></blockquote>
<div class=""><br class="">
Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list
at:<br class="">
<br class=""></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div>
<div class=""><br class=""></div>
</blockquote>
<div class="">or, if you would like to keep your feedback private,
directly to the review manager. When replying, please try to keep
the&nbsp;proposal link at the top of the message:<br class="">
<br class=""></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class="">Proposal link:</div>
</blockquote>
<div class=""><br class=""></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md</a></div>
</blockquote>
</blockquote>
<div class=""><br class=""></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class="">Reply text</div>
</blockquote>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class="">Other replies</div>
</blockquote>
<div class=""><br class=""></div>
<div class=""><b class="">What goes into a review?</b><br class="">
<br class="">
The goal of the review process is to improve the proposal under
review through constructive criticism and,
eventually,&nbsp;determine the direction of Swift. When writing
your review, here are some questions you might want to answer in
your&nbsp;review:<br class="">
<br class="">
<div class="">• What is your evaluation of the proposal?<br class=""></div>
<div class="">• Is the problem being addressed significant enough
to warrant a change to Swift?<br class=""></div>
<div class="">• Does this proposal fit well with the feel and
direction of Swift?<br class=""></div>
<div class="">• If you have used other languages or libraries with
a similar feature, how do you feel that this proposal compares
to&nbsp;those?<br class=""></div>
<div class="">• How much effort did you put into your review? A
glance, a quick reading, or an in-depth study?<br class=""></div>
<div class=""><br class=""></div>
More information about the Swift evolution process is available
at:<br class="">
<br class=""></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class=""><a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Thank you,</div>
<div class=""><br class="">
-Joe<br class="">
Review Manager<br class=""></div>


_______________________________________________<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>