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.

Sign up for GitHub

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

Jump to bottom

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

Closed
jtbandes opened this issue Aug 9, 2016 · 5 comments
Closed

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

jtbandes opened this issue Aug 9, 2016 · 5 comments
Assignees
@beccadax
Labels
compiler The Swift compiler in itself feature A feature request or implementation improvement standard library Area: Standard library umbrella swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented

Comments

@jtbandes
Copy link
Collaborator

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
}
@benrimmington
Copy link
Collaborator 

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

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

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

@Dante-Broggi
Copy link
Contributor

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

@beccadax
Copy link
Contributor

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
@AnthonyLatsis AnthonyLatsis added compiler The Swift compiler in itself swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented labels Nov 11, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@beccadax beccadax

Labels
compiler The Swift compiler in itself feature A feature request or implementation improvement standard library Area: Standard library umbrella swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jtbandes @benrimmington @beccadax @AnthonyLatsis @Dante-Broggi