[swift-evolution] Strings in Swift 4

[Joe Groff]

> 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 <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. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170120/5803efc9/attachment.html>