Found it: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021548.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021548.html>
Saagar Jha > On Jan 20, 2017, at 4:10 AM, Charlie Monroe via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Please see discussion inline. >> >> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira >> <jeremy.j.pere...@googlemail.com <mailto:jeremy.j.pere...@googlemail.com>> >> wrote: >> >> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution >> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > >> > One ask - make string interpolation great again? >> > >> > Taking from examples supplied at >> > https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation >> > >> > <https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation> >> > >> > "Column 1: \(n.format(radix:16, width:8)) *** \(message)" >> > >> > Why not use: >> > >> > "Column 1: ${n.format(radix:16, width:8)} *** $message" >> > >> > 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]. >> > >> >> This idea came up once before on Swift Evo. The arguments against are: >> >> 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. >> >> >> 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. > > Hi Maxim, > > 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". > >> >> 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. >> >> >> 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. >> >> 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. >> >> 3. There is already quite a lot of code that uses \( … ) for interpolation, >> this would be a massive breaking change. >> >> >> 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. >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
