[swift-evolution] Strings in Swift 4

[Jeremy Pereira]

> On 20 Jan 2017, at 11:55, Maxim Veksler <maxim at vekslers.org> wrote:
> 
> Please see discussion inline.
> 
> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:
> 
> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution <swift-evolution at 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
> >
> > "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.

I agree there is a difference. \t inserts a tab at compile time whereas \( … ) inserts the expression converted to a string at run time. However, I don’t agree that the distinction is sufficient to require a different character to introduce the non literal bit. I presume you are quite comfortable with

    let a = 3 + 4
    let b = x + y

both using the + symbol even though the former is evaluated entirely by the compiler.


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

Of what? Of disasters that have arisen through using the $ character? I admit the adjective was a bit over the top, “bad” would have been more accurate.

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

Well thats seems quite a lot more ugly than the status quo to me.

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

I wish they wouldn’t. 

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


I disagree. I think the \( … ) is just as readable as ${ … }. Actually, I would have been OK with \{ … } but I think that ship has sailed because of the existing code base using \( … ).