<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Please see discussion inline.<div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira &lt;<a href="mailto:jeremy.j.pereira@googlemail.com" class="">jeremy.j.pereira@googlemail.com</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
&gt; On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; One ask - make string interpolation great again?<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; Taking from examples supplied at <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation</a><br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; "Column 1: \(n.format(radix:16, width:8)) *** \(message)"<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; Why not use:<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; "Column 1: ${n.format(radix:16, width:8)} *** $message"<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; Which for my preference makes the syntax feel more readable, avoids the "double ))" in terms of string interpolation termination and function termination points. And if that's not enough brings the "feel" of the language to be scriptable in nature common in bash, sh, zsh and co.. scripting interpreters and has been adopted as part of ES6 interpolation syntax[1].<br class="gmail_msg">
&gt;<br class="gmail_msg">
<br class="gmail_msg">
This idea came up once before on Swift Evo. The arguments against are:<br class="gmail_msg">
<br class="gmail_msg">
1. Swift already has an “escape” character for inserting non literal stuff into strings - the “\” character. Either you have two - increasing complexity for both the developer and the Swift compiler’s tokeniser - or you have to change everything that uses “\” to use $ e.g. $t $n instead of \t \n.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div class=""><br class=""></div><div class="">I would claim that this serves as an reinforcement of making the distinctions. "\t"&nbsp;is not the same behavior as "\(someVariable)" both conceptually - I think there is a clear distinction between inserting a "constant symbol" to inserting "the string content of a variable" and semantically - While you would use \t to insert a tab you are mandated by the semantics to use \( .. ) to insert the contents of a variable.</div></div></div></div></div></blockquote><div><br class=""></div><div>Hi Maxim,</div><div><br class=""></div><div>there was quite a discussion on this matter a few months ago - I can't find the thread right now, but the consensus of majority here seemed to be that the current status is desirable by most and that it contains some unified philosophy over anything that will "not print as typed". I believe that this is something that has been discussed here several times - keep in mind Swift 4 is supposed to be as much backward compatible as possible with breaking changes requiring severe justification - there is unlikely to be one for this other than "I like it better this way".</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class="">&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. The dollar sign is a disastrous symbol to use for an special character, especially in the USA where it is commonly used to signify the local currency. Yes, I know it is used for interpolation in Perl, Shell and Javascript and others,&nbsp; but “this other language I like does X, therefore Swift should do X” is not a good argument.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div class=""><br class=""></div><div class="">Please name concrete examples? I would believe that the case for $variableName to be rare enough to justify expecting the developer to make an escape claim with \$variableName, likewise for ${variableName}, if expected output is plain text I wouldn't imagine this "\$\{variableName\}" to be a far reaching expectation.</div><div class=""><br class=""></div><div class="">The use of $ symbol is more reaching[1], and is being adopted constantly as the selected patten for even recent developments as Facebook's GraphQL query syntax[2] which to the best of my knowledge was invented in US.&nbsp;</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. There is already quite a lot of code that uses \( … ) for interpolation, this would be a massive breaking change.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div class=""><br class=""></div><div class="">True, but going forward that would enable a "better readable" code for larger number of users. Additionally I would suggest that automatic conversion using Swift Migration Assistant should be possible.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>