Hi Dave, I just filed https://bugs.swift.org/browse/SR-2303.
Brainstorming: is it important that the init(stringInterpolation:) and init(stringInterpolationSegment:) requirements are on the same type? Perhaps it would work to separate these two requirements, allowing the segments to construct intermediate types, and only requiring the type adopting ExpressibleByStringInterpolation to implement init(stringInterpolation:). This would be nice because it would be much easier for types which aren't enums to conform to ExpressibleByStringInterpolation. In my auto layout example (https://gist.github.com/jtbandes/9c1c25ee4996d2554375), the ConstraintCollection type is only an enum because it has to provide all the initializers, but it's strange that the cases are accessible publicly; ideally it would just be a struct with no public initializers besides init(stringInterpolation:). For example: enum InterpolationSegment<T: InterpolationSegmentProtocol> { case stringLiteral(String) case interpolatedValue(T) } protocol InterpolationSegmentProtocol { // Might want to implement init(stringInterpolationSegment:) for multiple types, // so we can't require a single associated value (same with ExpressibleByStringLiteral today) // associatedtype Value // init(stringInterpolationSegment value: Value) } protocol MyExpressibleByStringInterpolation { associatedtype Segment: InterpolationSegmentProtocol init(stringInterpolation: InterpolationSegment<Segment>...) } // Foo is constructed from a string interpolation containing only // String pieces and Foo.Segment pieces. struct Foo: MyExpressibleByStringInterpolation { struct Segment: InterpolationSegmentProtocol { init(stringInterpolationSegment value: Int) {} init(stringInterpolationSegment value: Double) {} } init(stringInterpolation: InterpolationSegment<Segment>...) { // ... } } let x: Foo = "abc\(3)def" // translated to Foo(stringInterpolation: .stringLiteral("abc"), .interpolatedValue(.init(stringInterpolationSegment: 3)), .stringLiteral("def")) Jacob On Mon, Aug 8, 2016 at 5:57 PM, Dave Abrahams via swift-evolution < [email protected]> wrote: > > on Sat Jul 30 2016, Jacob Bandes-Storch <[email protected]> wrote: > > > 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 > > Hi Jacob, > > 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. > > Thanks, > > > 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 > > > > -- > -Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
