> On 20 Jan 2017, at 11:55, Maxim Veksler <[email protected]> wrote:
>
> Please see discussion inline.
>
> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira
> <[email protected]> wrote:
>
> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution
> > <[email protected]> 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 \( … ).
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
