[swift-evolution] Strings in Swift 4

[Dave Abrahams]

on Fri Jan 20 2017, Joe Groff <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:
>> 
>> 
>> 
>> 
>
>> 
>> 
>> 
>> 
>>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull <jhull at gbis.com <mailto: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. 

Yes.

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

I agree.

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

Maybe so.  But let's try not to get too caught up in the specifics of
formatting, as that's really not something we want to deal with right
now.

-- 
-Dave