<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@swift.org> wrote:
>
>>
>> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>>
>> Sent from my iPad
>>
>>
>>
>> Sent from my iPad
>>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull <jh...@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
