<div dir="ltr">Please see discussion inline.<div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira <<a href="mailto:jeremy.j.pereira@googlemail.com">jeremy.j.pereira@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> One ask - make string interpolation great again?<br class="gmail_msg">
><br class="gmail_msg">
> 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">
><br class="gmail_msg">
> "Column 1: \(n.format(radix:16, width:8)) *** \(message)"<br class="gmail_msg">
><br class="gmail_msg">
> Why not use:<br class="gmail_msg">
><br class="gmail_msg">
> "Column 1: ${n.format(radix:16, width:8)} *** $message"<br class="gmail_msg">
><br class="gmail_msg">
> 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">
><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><br></div><div>I would claim that this serves as an reinforcement of making the distinctions. "\t" 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><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, 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><br></div><div>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><br></div><div>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. </div><div><br></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><br></div><div>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><br></div><div><br></div></div></div></div>