[SR-2303] ExpressibleByStringInterpolation: ability to restrict types used in string interpolation

[jtbandes]

Previous ID	SR-2303
Radar	None
Original Reporter	@jtbandes
Type	Improvement
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	1
Component/s	Standard Library
Labels	Improvement, LanguageFeatureRequest
Assignee	@beccadax
Priority	Medium

md5: d86f9995a0b9dc90aad8b59b81c4bab2

relates to:

• SR-1260 ExpressibleByStringInterpolation: can't distinguish between literal components and String arguments
• SR-3969 Improve ExpressibleByStringInterpolation

Issue Description:

It's desirable for types conforming to ExpressibleByStringInterpolation to be able to restrict the kinds of values that can be used in string interpolation.

The following example is a simplified version of brentdax (JIRA User)'s example from the swift-evolution thread:

// We want LocalizedString to be formed from a string interpolation;
// only LocalizedStringConvertible values should be allowed as interpolated values.

protocol LocalizedStringConvertible { ... }
struct LocalizedString { ... }

extension LocalizedString: ExpressibleByStringInterpolation {
    init(stringInterpolation segments: LocalizedString...) { }
    init(stringInterpolationSegment value: LocalizedStringConvertible) { ... }
    // no init<T>(stringInterpolationSegment:) is provided; only LocalizedStringConvertible values are valid
}

[benrimmington]

extension LocalizedString: ExpressibleByStringInterpolation {

 @available(*, unavailable, message: "use LocalizedStringConvertible value")
 public init<T>(stringInterpolationSegment _: T) {
     fatalError()
 }

 public init(stringInterpolationSegment value: LocalizedStringConvertible) {
     /*...*/
 }

 public init(stringInterpolation segments: LocalizedString...) {
     /*...*/
 }
}

[beccadax]

@benrimmington, this makes the code compile, but it doesn't behave the way you'd want it to—literal segments are interpreted as being of type String and are indistinguishable from non-literal segments, except by index in the segments array. (Even segments are literal.) Providing a specific LocalizedString overload doesn't solve this issue, and from what I can tell, giving Swift any opportunity—however indirect—to accept an interpolated String will cause all literal segments to come in as String as well.

[benrimmington]

This workaround is only for SR-2303 (it doesn't resolve SR-1260).

[Dante-Broggi]

I think this can be closed due to SE-0228 (Fix ExpressibleByStringInterpolation).

[beccadax]

Resolved by SE-0228. The available appendInterpolation overloads determine which types can be interpolated into a string literal.