<div dir="ltr">Here's another example use case: Auto Layout visual format strings.<div><br></div><div><a href="https://gist.github.com/jtbandes/9c1c25ee4996d2554375#file-constraintcollection-swift-L85-L87" target="_blank">https://gist.github.com/jtbandes/9c1c25ee4996d2554375#file-constraintcollection-swift-L85-L87</a><br></div><div><br></div><div>Since only views and numeric types are supported, the generic init<T> has to be a run-time error. Ideally it could be a compile-time error.</div><div class="gmail_extra">
<br><div class="gmail_quote">On Tue, Aug 2, 2016 at 6:10 PM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</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>> On Jul 30, 2016, at 10:35 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> In the past, there has been some interest in refining the behavior of ExpressibleByStringInterpolation (née StringInterpolationConvertible), for example:<br>
><br>
> - Ability to restrict the types that can be used as interpolation segments<br>
> - Ability to distinguish the string-literal segments from interpolation segments whose type is String<br>
><br>
> Some prior discussions:<br>
> - "StringInterpolationConvertible and StringLiteralConvertible inheritance" <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html</a><br>
> - Sub-discussion in "Allow multiple conformances to the same protocol" <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html</a><br>
> - "StringInterpolationConvertible: can't distinguish between literal components and String arguments" <a href="https://bugs.swift.org/browse/SR-1260" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/SR-1260</a> / rdar://problem/19800456&18681780<br>
> - "Proposal: Deprecate optionals in string interpolation" <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html</a><br>
><br>
><br>
> About Swift 4, Chris wrote:<br>
> - 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!<br>
><br>
> 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.<br>
><br>
> Discuss!<br>
<br>
</span>I'm not one of the core team, so all I can really provide is a use case.<br>
<br>
Given a LocalizedString type like:<br>
<br>
/// Conforming types can be included in a LocalizedString.<br>
protocol LocalizedStringConvertible {<br>
/// The format to use for this instance. This format string will be included in the key when<br>
/// this type is interpolated into a LocalizedString.<br>
var localizedStringFormat: String { get }<br>
<br>
/// The arguments to use when formatting to represent this instance.<br>
var localizedStringArguments: [CVarArg] { get }<br>
}<br>
<br>
extension NSString: LocalizedStringConvertible {…}<br>
extension String: LocalizedStringConvertible {…}<br>
extension LocalizedString: LocalizedStringConvertible {…}<br>
<br>
extension Int: LocalizedStringConvertible {…}<br>
// etc.<br>
<br>
struct LocalizedString {<br>
/// Initializes a LocalizedString by applying the `arguments` to the format string with the<br>
/// indicated `key` using `String.init(format:arguments:)`.<br>
///<br>
/// If the `key` does not exist in the localized string file, the `key` itself will be used as<br>
/// the format string.<br>
init(key: String, formattedWith arguments: [CVarArg]) {…}<br>
}<br>
<br>
extension String {<br>
init(_ localizedString: LocalizedString) {<br>
self.init(describing: localizedString)<br>
}<br>
}<br>
<br>
extension LocalizedString {<br>
/// Initializes a LocalizedString with no arguments which uses the indicated `key`. `%`<br>
/// characters in the `key` will be converted to `%%`.<br>
///<br>
/// If the `key` does not exist in the localized string file, the `key` itself will be used as<br>
/// the string.<br>
init(key: String) {…}<br>
<br>
/// Initializes a LocalizedString to represent the indicated `value`.<br>
init(_ value: LocalizedStringConvertible) {…}<br>
<br>
/// Initializes a LocalizedString to represent the empty string.<br>
init() {…}<br>
}<br>
<br>
extension LocalizedString: CustomStringConvertible {…}<br>
<br>
extension LocalizedString: ExpressibleByStringLiteral {<br>
init(stringLiteral value: String) {<br>
self.init(key: value)<br>
}<br>
…<br>
}<br>
<br>
The current ExpressibleByStringInterpolation protocol has a number of defects.<br>
<br>
1. We want to only permit LocalizedStringConvertible types, or at least *use* the LocalizedStringConvertible conformance; neither of these appears to be possible. (`is` and `as?` casts always fail, overloads don't seem to be called, etc.)<br>
<br>
2. The literal parts of the string are interpreted using `String`'s `ExpressibleByStringLiteral` conformance; we really want them to use `LocalizedString`'s instead.<br>
<br>
3. We don't want the literal parts of the string to pass through `init(stringInterpolationSegment:)`, because we want to treat interpolation and literal segments differnetly.<br></blockquote><div><br></div><div>Yep, this is what I filed <a href="https://bugs.swift.org/browse/SR-1260" target="_blank">https://bugs.swift.org/browse/SR-1260</a> for.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In other words, we want to be able to write something like this:<br>
<br>
extension LocalizedString: ExpressibleByStringInterpolation {<br>
typealias StringInterpolatableType = LocalizedStringConvertible<br>
<br>
init(stringInterpolation segments: LocalizedString) {<br>
self.init()<br>
for segment in segments {<br>
formatKey += segment.formatKey<br>
arguments += segment.arguments<br>
}<br>
}<br>
<br>
init(stringInterpolationSegment expr: LocalizedStringConvertible) {<br>
self.init(expr)<br>
}<br>
}<br>
<br>
And change the code generated by the compiler from (given the statement `"foo \(bar) baz" as LocalizedString`) this:<br>
<br>
LocalizedString(stringInterpolation:<br>
LocalizedString(stringInterpolationSegment: String(stringLiteral: "foo ")),<br>
LocalizedString(stringInterpolationSegment: bar),<br>
LocalizedString(stringInterpolationSegment: String(stringLiteral: " baz"))<br>
)<br>
<br>
To this:<br>
<br>
LocalizedString(stringInterpolation:<br>
LocalizedString(stringLiteral: "foo "),<br>
LocalizedString(stringInterpolationSegment: bar),<br>
LocalizedString(stringLiteral: " baz")<br>
)<br>
<br>
This would obviously require a few changes to the ExpressibleAsStringInterpolation protocol:<br>
<br>
// You cannot accept interpolations unless you can also be a plain literal.<br>
// Necessary for literal segments.<br>
protocol ExpressibleByStringInterpolation: ExpressibleByStringLiteral {<br>
// An associated type for the type of a permitted interpolation<br>
associatedtype StringInterpolatableType = Any<br>
<br>
// No changes here<br>
init(stringInterpolation segments: Self...)<br>
<br>
// No longer generic; instead uses StringInterpolatableType existentials.<br>
// Also a semantic change: this is only called for the actual interpolations.<br>
// init(stringLiteral:) is called for literal segments.<br>
init(stringInterpolationSegment expr: StringInterpolatableType)<br>
<br>
// Given the change in roles, we might want to consider renaming the initializers:<br>
//<br>
// init(stringInterpolation:) => init(combinedStringLiteral:) or init(stringInterpolationSegments:)<br>
// init(stringInterpolationSegment:) => init(stringInterpolation:)<br>
}<br>
<br>
Or perhaps we would hoist the combining initializer up into ExpressibleAsStringLiteral, and generate an `init(combinedStringLiteral:)` call every time string literals are used.<br>
<br>
protocol ExpressibleByStringLiteral {<br>
associatedtype StringLiteralType: _ExpressibleByBuiltinStringLiteral = String<br>
<br>
init(stringLiteralSegments segments: Self...)<br>
init(stringLiteral value: StringLiteralType)<br>
}<br>
<br>
protocol ExpressibleByStringInterpolation: ExpressibleByStringLiteral {<br>
associatedtype StringInterpolatableType = Any<br>
<br>
init(stringInterpolation expr: StringInterpolatableType)<br>
}<br>
<br>
// "foo" as LocalizedString<br>
LocalizedString(stringLiteralSegments:<br>
LocalizedString(stringLiteral: "foo")<br>
)<br>
<br>
// "foo \(bar) baz" as LocalizedString<br>
LocalizedString(stringInterpolation:<br>
LocalizedString(stringLiteral: "foo "),<br>
LocalizedString(stringInterpolation: bar),<br>
LocalizedString(stringLiteral: " baz")<br>
)<br>
<br>
Now, it's quite possible--perhaps even likely--that there are really good reasons for the current design. But I've been thinking about this for two years and I don't know what they are yet; nor can I find much relevant design documentation. I, too, would love to find out why the current design was selected.<br>
<span><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></div><br></div></div>