[swift-evolution] Strings in Swift 4

[Sean Heber]

<bikeshed>

Syntax-wise, it almost seems like there shouldn’t be a comma after the variable name because then it looks like an argument to a function. What if it was just a space?

"now you have \(n radix: 16, width: 2) problems"

Anyway, this seems cool. :)

l8r
Sean






> On Jan 20, 2017, at 1:19 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>> 
>> 
>> Sent from my iPad
>>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull <jhull at gbis.com> wrote:
>>> 
>>> Thanks for all the hard work!
>>> 
>>> Still digesting, but I definitely support the goal of string processing even better than Perl.  Some random thoughts:
>>> 
>>> • I also like the suggestion of implicit conversion from substring slices to strings based on a subtype relationship, since I keep running into that issue when trying to use array slices.  
>> 
>> Interesting.  Could you offer some examples?
>> 
>>> It would be nice to be able to specify that conversion behavior with other types that have a similar subtype relationship.
>> 
>> Indeed.
>> 
>>> • One thing that stood out was the interpolation format syntax, which seemed a bit convoluted and difficult to parse:
>>>> "Something with leading zeroes: \(x.format(fill: zero, width:8))"
>>> 
>>> 
>>> Have you considered treating the interpolation parenthesis more like the function call syntax?  It should be a familiar pattern and easily parseable to someone versed in other areas of swift:
>>> 
>>>   “Something with leading zeroes: \(x, fill: .zero, width: 8)"
>> 
>> Yes, we've considered it
>> 
>>  1. "\(f(expr1, label2: expr2, label3: expr3))" 
>> 
>>     String(describing: f(expr1, label2: expr2, label3: expr3))
>> 
>>  2. "\(expr0 + expr1(label2: expr2, label3: expr3))"
>> 
>>     String(describing: expr0 + expr1(label2: expr2, label3: expr3)
>> 
>>  3. "\((expr1, label2: expr2, label3: expr3))"
>> 
>>     String(describing: (expr1, label2: expr2, label3: expr3))
>> 
>>  4. "\(expr1, label2: expr2, label3: expr3)"
>> 
>>     String(describing: expr1, label2: expr2, label3: expr3)
>> 
>> I think I'm primarily concerned with the differences among cases 1, 3,
>> and 4, which are extremely minor.  3 and 4 differ by just a set of
>> parentheses, though that might be mitigated by the ${...} suggestion someone else posted.  The point of using string interpolation is to improve
>> readability, and I fear these cases make too many things look alike that
>> have very different meanings.  Using a common term like "format" calls
>> out what is being done.
> 
> We should look at this part of the problem as part of reconsidering the way string interpolation works as a whole; there are other problems with our current model, such as not being able to distinguish literal and non-literal segments. I fear that even this:
> 
>> It's possible to produce terser versions of the syntax that don't suffer
>> from this problem by using a dedicated operator:
>> 
>>  "Column 1: \(n⛄(radix:16, width:8)) *** \(message)"
>>  "Something with leading zeroes: \(x⛄(fill: zero, width:8))"
> 
> has too many nested delimiters to be easily readable. If we had a string interpolation protocol something like this:
> 
> protocol ExpressibleByStringInterpolation {
>   associatedtype LiteralSegment: ExpressibleByStringLiteral
>   associatedtype InterpolatedSegment
>   init()
> 
>   mutating func append(literalSegment: LiteralSegment)
>   mutating func append(interpolatedSegment: InterpolatedSegment)
> }
> 
> and "now you have \(n, radix: 16, width: 2) problems" in 'Thingy' context desugared so that \() became a constructor call on the InterpolatedSegment type:
> 
> {
>   var x = Thingy()
>   x.append(literalSegment: "now you have ")
>   x.append(interpolatedSegment: Thingy.InterpolatedSegment(n, radix: 16, width: 2))
>   x.append(literalSegment: " problems")
>   return x
> }()
> 
> then String.InterpolatedSegment could be a struct that offers interesting formatting initializers.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution