<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" 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></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">What is your evaluation of the proposal?</div></div></div></blockquote><div><br class=""></div>+1</div><div><br class=""></div><div>My foremost expectation from multiline string literals is to be able to copy and paste multiline string literals without having to fiddle with escape marks or leading and trailing quotes or continuation characters. This is exactly what the proposal provides and makes it easy to embed SQL, for example (using SQL parameters and not string interpolation of course ;-)</div><div><br class=""></div><div>The chosen deindentation rules seem very pragmatic and useful to me.</div><div><br class=""></div><div>Additional features for multiline string literals can be added easily later.</div><div><br class=""></div><div>I would expect multiline string literals to use the same newline character as "\n“ does, regardless of the newline character actually used in the file.</div><div>Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as well. </div><div>This should be stated explicitly in the proposal.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>Yes.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></div></div></blockquote><div><br class=""></div>Yes.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></div></div></blockquote><div><br class=""></div>For setting the ground it compares favourably.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></div></blockquote><br class=""></div><div>Followed most discussions, read the proposal.</div><div><br class=""></div><div>-Thorsten</div><br class=""></body></html>