[swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex
dabrahams at apple.com
Mon Aug 8 19:57:02 CDT 2016
on Sat Jul 30 2016, Jacob Bandes-Storch <swift-evolution at swift.org> wrote:
> In the past, there has been some interest in refining the behavior of
> ExpressibleByStringInterpolation (née StringInterpolationConvertible), for
> - Ability to *restrict the types that can be used* as interpolation segments
> - Ability to *distinguish the string-literal segments* from interpolation
> segments whose type is String
I see you've already filed a Jira for the second bullet. Can you file
one for the first one? We're going to redesign
ExpressibleByStringInterpolation for Swift 4 and solve these problems.
> Some prior discussions:
> - "StringInterpolationConvertible and StringLiteralConvertible inheritance"
> - Sub-discussion in "Allow multiple conformances to the same protocol"
> - "StringInterpolationConvertible: can't distinguish between literal
> components and String arguments" https://bugs.swift.org/browse/SR-1260
> / rdar://problem/19800456&18681780
> - "Proposal: Deprecate optionals in string interpolation"
> About Swift 4, Chris wrote:
>> - *String re-evaluation:* String is one of the most important
>> fundamental types in the language. The standard library leads have
>> numerous ideas of how to improve the programming model for it, without
>> jeopardizing the goals of providing a unicode-correct-by-default model.
>> Our goal is to be better at string processing than Perl!
> I'd be interested in any more detail the team can provide on this. I'd like
> to talk about string interpolation improvements, but it wouldn't be wise to
> do so without keeping an eye towards possible regex/pattern-binding syntax,
> and the String refinements that the stdlib team has in mind, if there's a
> chance they would affect interpolation.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution