on Fri Jan 20 2017, Joe Groff <[email protected]> wrote:
>> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>>
>>
>>
>>
>
>>
>>
>>
>>
>>> 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.
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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
