[swift-evolution] Strings in Swift 4

[Saagar Jha]

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 at swift.org> wrote:
> 
>> 
>> On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Please see discussion inline.
>> 
>> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira <jeremy.j.pereira at googlemail.com <mailto:jeremy.j.pereira at googlemail.com>> wrote:
>> 
>> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution <swift-evolution at swift.org <mailto: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 <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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170120/6c918092/attachment.html>