<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 12:01 PM, Charlie Monroe <span dir="ltr">&lt;<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>&gt;</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"><div><div>Hi Nicola, thanks for the feedback.<br>
<br>
&gt; I assume you mean &quot;at runtime&quot; here?<br>
<br>
That&#39;s probably my wrong wording. :) The unexpected result is at runtime, but we&#39;d like to catch this at compile time. I&#39;ve updated it to say<br>
<br>
&quot;in order to prevent unexpected results already at compile time&quot; - hopefully that&#39;s a clearer wording.<br></div></div></blockquote><div><br></div><div>Aha, now I understand :-)<br><br></div><div>Perhaps &quot;in order to detect potentially undesired behavior at compile time&quot; would be even clearer?<br></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"><div><div>
<br>
&gt; I think the detailed design needs  some more thought. The &quot;Uninterpolable&quot;<br>
&gt; protocol, and suggesting to cast &quot;as Any&quot; in a Fix-it both seem hacks.<br>
<br>
Originally, the proposal was simply to emit a warning for interpolation of Optionals, but several people made good points:<br>
<br>
- there may be other types you may not want to use for interpolation - as mentioned in the proposal, e.g. private data structures that would expose something you want to keep private, various enum values, etc. Which is why I&#39;ve started thinking about making a protocol that would indicate the type is discouraged being &quot;interpoled&quot;. I&#39;ve thought about this and decided to make a more robust and customizable solution.<br></div></div></blockquote><div><br></div><div>I&#39;m not sure if this is a strong enough motivation.<br>The customization point already provided by the language is CustomStringConvertible. That&#39;s the place where one can provide a readable description, hiding implementation details.<br></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"><div><div>
<br>
An alternative to this would be to use annotations or just drop this customizability completely. But I think with Swift and its protocol-driven development, marking the type with this protocol is the most robust way to go.<br>
<br>
- both .description and .debugDescription are mentioned in alternatives for the Fix-It.<br></div></div></blockquote><div><br></div><div>The direct use of .description and .debugDescription is discouraged in the API docs, so I don&#39;t think this is a viable option.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<br>
&quot;as Any&quot; seemed, however, the cleanest and most robust solution to me, since then the Uninterpolable protocol can be applied to any type without forcing the type to conform to CustomStringConvertible as well. I agree that it&#39;s kind of a hack, though.<br>
<br>
&gt; I&#39;m not even sure if the general direction of a compile time warning is the<br>
&gt; right one, and if the problem wouldn&#39;t be better solved by simply not making<br>
&gt; Optional put &quot;Optional()&quot; around the value in its .description.<br>
<br>
There are many people oposing this and expecting the Optional() wrap around the value, indicating the actual type. Actually, including me - I agree it can be useful for some types of debugging since in what you wrote further, there&#39;d be no difference between description of [1, 2, 3] (i.e. [Int]) and Optional([1, 2, 3]) (i.e. [Int]?).<br></div></div></blockquote><div><br></div><div>There&#39;s also no difference between print(Int(1)) and print(UInt(1)): they both output just &quot;1&quot;.<br></div><div><br>I think &quot;debugging&quot; is the key word here. If the distinction between CustomStringConvertible and CustomDebugStringConvertible is supposed to be between providing a user-friendly description and a description useful for debugging, I think it makes sense to make the former as terse as possible and the latter as informative as possible.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<br>
There are legitimate usecases where the current behavior is correct, but in most of cases, having an optional in string interpolation will lead either to unnecessary clutter in the log/console or bugs - in which case even &quot;nil&quot; is not correct to be used for the interpolation. Which is the basis for this proposal.<br>
<br>
&gt; print(&quot;\(o)&quot;)               // &quot;Optional(1)&quot;, why??<br>
<br>
String has several overloads for the init(stringInterpolationSegment:) initiailizer. Optional falls into the generic &lt;T&gt; category, which will call String(optional) - which most likely uses debugDescription.<br>
<br>
</div></div></blockquote></div><br></div><div class="gmail_extra">This is the relevant code:<br><a href="https://github.com/apple/swift/blob/cf73dd9177c231a15429b08ae889e94f20e53f50/stdlib/public/core/OutputStream.swift#L322-L331" target="_blank">https://github.com/apple/swift/blob/cf73dd9177c231a15429b08ae889e94f20e53f50/stdlib/public/core/OutputStream.swift#L322-L331</a><br><br></div><div class="gmail_extra">I presume that it shouldn&#39;t be a problem to change it to use CustomStringConvertible instead.<br><br></div><div class="gmail_extra">The above code also hints that there&#39;s another odd behavior in the current implementation:<br><br>struct Foo: CustomStringConvertible, CustomDebugStringConvertible {<br>    var description: String { return &quot;normal&quot; }<br>    var debugDescription: String { return &quot;debug&quot; }<br>}<br><br>let f = Foo()<br>let of = Optional(f)<br><br>print(f)        // &quot;normal&quot;: ok<br>debugPrint(f)   // &quot;debug&quot;: ok<br>print(of)       // &quot;Optional(debug)&quot;: unexpected<br>debugPrint(of)  // &quot;Optional(debug)&quot;: ok<br><br>--<br></div><div class="gmail_extra">Nicola<br><br></div></div>