<div dir="ltr">Hi Dave,<div>I just filed <a href="https://bugs.swift.org/browse/SR-2303">https://bugs.swift.org/browse/SR-2303</a>.</div><div><br></div><div>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:).</div><div><br></div><div>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 (<a href="https://gist.github.com/jtbandes/9c1c25ee4996d2554375">https://gist.github.com/jtbandes/9c1c25ee4996d2554375</a>), 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:</div><div><br></div><div><div> enum InterpolationSegment<T: InterpolationSegmentProtocol> {</div><div> case stringLiteral(String)</div><div> case interpolatedValue(T)</div><div> }</div><div><br></div><div> protocol InterpolationSegmentProtocol {</div><div> // Might want to implement init(stringInterpolationSegment:) for multiple types,</div><div> // so we can't require a single associated value (same with ExpressibleByStringLiteral today)</div><div> // associatedtype Value</div><div> // init(stringInterpolationSegment value: Value)</div><div> }</div><div><br></div><div> protocol MyExpressibleByStringInterpolation {</div><div> associatedtype Segment: InterpolationSegmentProtocol</div><div> init(stringInterpolation: InterpolationSegment<Segment>...)</div><div> }</div><div><br></div><div> // Foo is constructed from a string interpolation containing only</div><div> // String pieces and Foo.Segment pieces.</div><div> struct Foo: MyExpressibleByStringInterpolation {</div><div> struct Segment: InterpolationSegmentProtocol {</div><div> init(stringInterpolationSegment value: Int) {}</div><div> init(stringInterpolationSegment value: Double) {}</div><div> }</div><div> init(stringInterpolation: InterpolationSegment<Segment>...) {</div><div> // ...</div><div> }</div><div> }</div><div><br></div><div> let x: Foo = "abc\(3)def"</div><div> // translated to</div><div> Foo(stringInterpolation:</div><div> .stringLiteral("abc"),</div><div> .interpolatedValue(.init(stringInterpolationSegment: 3)),</div><div> .stringLiteral("def"))</div></div><div><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Mon, Aug 8, 2016 at 5:57 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
on Sat Jul 30 2016, Jacob Bandes-Storch <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> In the past, there has been some interest in refining the behavior of<br>
> ExpressibleByStringInterpolati<wbr>on (née StringInterpolationConvertible<wbr>), for<br>
> example:<br>
><br>
</span>> - Ability to *restrict the types that can be used* as interpolation segments<br>
> - Ability to *distinguish the string-literal segments* from interpolation<br>
<span class="gmail-">> segments whose type is String<br>
<br>
</span>Hi Jacob,<br>
<br>
I see you've already filed a Jira for the second bullet. Can you file<br>
one for the first one? We're going to redesign<br>
ExpressibleByStringInterpolati<wbr>on for Swift 4 and solve these problems.<br>
<br>
Thanks,<br>
<span class="gmail-"><br>
> Some prior discussions:<br>
> - "<wbr>StringInterpolationConvertible and StringLiteralConvertible inheritance"<br>
> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20160516/017654.<wbr>html</a><br>
> - Sub-discussion in "Allow multiple conformances to the same protocol"<br>
> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20160606/020746.<wbr>html</a><br>
> - "<wbr>StringInterpolationConvertible<wbr>: can't distinguish between literal<br>
> components and String arguments" <a href="https://bugs.swift.org/browse/SR-1260" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/<wbr>SR-1260</a><br>
> / rdar://problem/19800456&<wbr>18681780<br>
> - "Proposal: Deprecate optionals in string interpolation"<br>
> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20160516/018000.<wbr>html</a><br>
><br>
> About Swift 4, Chris wrote:<br>
><br>
</span>>> - *String re-evaluation:* String is one of the most important<br>
<span class="gmail-">>> fundamental types in the language. The standard library leads have<br>
>> numerous ideas of how to improve the programming model for it, without<br>
>> jeopardizing the goals of providing a unicode-correct-by-default model.<br>
>> Our goal is to be better at string processing than Perl!<br>
><br>
> I'd be interested in any more detail the team can provide on this. I'd like<br>
> to talk about string interpolation improvements, but it wouldn't be wise to<br>
> do so without keeping an eye towards possible regex/pattern-binding syntax,<br>
> and the String refinements that the stdlib team has in mind, if there's a<br>
> chance they would affect interpolation.<br>
><br>
> Discuss!<br>
><br>
> -Jacob<br>
</span>> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
><br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</font></span></blockquote></div><br></div></div>