<div dir="ltr">You know what&#39;s worse than seeing &quot;Optional(my string value)&quot; in a label? Seeing &quot;nil&quot;. When the optional is there, it is made clear to the developer that the string they are showing <i>can be nil</i>. However, if you hide that from the users you are less likely to unwrap that optional and hence more likely to show the user &quot;nil&quot;. This behavior really goes against some of the core ideas of Swift - you want your code to be expressive but not abstract away potentially useful information.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 19, 2016 at 12:24 AM David Waite &lt;<a href="mailto:david@alkaline-solutions.com">david@alkaline-solutions.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Making string interpolation reject just optional (at compile time) when it doesn’t reject any other type sounds tricky to express.</div><div><br></div><div>What if instead Optional just didn’t decorate the wrapped value, outputting either the inner value or “nil” in these cases?</div><div><br></div><div>The debugDescription could remain &quot;Optional(data)&quot; style.</div></div><div style="word-wrap:break-word"><div><br></div><div>-DW</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On May 19, 2016, at 12:52 AM, Valentin via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="auto"><div>From what I understand of this thread, the argument here is that directly using an optional in a string interpolation is almost never what you really want to do (except mainly for debugging purposes) but you wouldn&#39;t see this mistake until much later at runtime.</div><div>And I feel like one of Swift goals is to enable us, imperfect human creatures, to detect as many problems or mistakes as possible long before runtime.</div><div><br>On 19 mai 2016, at 00:56, Dan Appel via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>-1. <br><br>Optional(foo) better depicts the actual type (it&#39;s an options string, after all). If you&#39;re not happy with it, just use the nil coalescing operator such as &quot;\(foo ?? &quot;&quot;)&quot;. This is from the same series of proposals as implicit casting - there are reasons it&#39;s done the way it is.<br><div class="gmail_quote"><div dir="ltr">On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>+1, personally I have taken to using `x+&quot;str&quot;+y` instead of `&quot;\(x)str\(y)&quot;`, if x/y are strings, so I can get a compile-time error if I do this accidentally.</div><div><br></div><div>But I do see the appeal of being able to print(&quot;the data: \(data)&quot;) for simple use cases. Didn&#39;t someone earlier propose some modifiers/labels like &quot;\(describing: x)&quot; ?</div></div><div dir="ltr"><div class="gmail_extra"><div><div><div dir="ltr"><div><br></div></div></div></div>
<br><div class="gmail_quote">On Wed, May 18, 2016 at 11:50 AM, Krystof Vasa via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The string interpolation is one of the strong sides of Swift, but also one of its weaknesses.<br>
<br>
It has happened to me more than once that I&#39;ve used the interpolation with an optional by mistake and the result is then far from the expected result.<br>
<br>
This happened mostly before Swift 2.0&#39;s guard expression, but has happened since as well.<br>
<br>
The user will seldomly want to really get the output &quot;Optional(something)&quot;, but is almost always expecting just &quot;something&quot;. I believe this should be addressed by a warning to force the user to check the expression to prevent unwanted results. If you indeed want the output of an optional, it&#39;s almost always better to use the ?? operator and supply a null value placeholder, e.g. &quot;\(myOptional ?? &quot;&lt;&lt;none&gt;&gt;&quot;)&quot;, or use myOptional.debugDescription - which is a valid expression that will always return a non-optional value to force the current behavior.<br>
<br>
Krystof<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><div><div>Dan Appel<br></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div><div dir="ltr">-- <br></div><div><div dir="ltr"><div><div>Dan Appel<br></div></div></div></div>