In the past, there has been some interest in refining the behavior of ExpressibleByStringInterpolation (née StringInterpolationConvertible), for example:
- 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 Some prior discussions: - "StringInterpolationConvertible and StringLiteralConvertible inheritance" https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html - Sub-discussion in "Allow multiple conformances to the same protocol" https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html - "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" https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html 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. Discuss! -Jacob
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
