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