> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
>
>
> Sent from my iPad
>
>
>
> Sent from my iPad
>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull <[email protected]
>> <mailto:[email protected]>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
