Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

jtbandes opened this issue Aug 9, 2016 · 5 comments


Copy link

@jtbandes jtbandes commented Aug 9, 2016

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
Copy link

@benrimmington benrimmington commented Aug 12, 2016

extension LocalizedString: ExpressibleByStringInterpolation {

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

 public init(stringInterpolationSegment value: LocalizedStringConvertible) {

 public init(stringInterpolation segments: LocalizedString...) {

Copy link

@beccadax beccadax commented Aug 13, 2016

@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.

Copy link

@benrimmington benrimmington commented Aug 13, 2016

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

Copy link

@Dante-Broggi Dante-Broggi commented Feb 9, 2019

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

Copy link

@beccadax beccadax commented Mar 9, 2019

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

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants