<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Consider the following example:<div class=""><br class=""></div><div class="">let originalURL: NSURL = NSURL(string: "<a href="http://apple.com/iphone" class="">http://apple.com/iphone</a>")!</div><div class="">let newURL = NSURL(string: "<a href="http://apple.com\(originalurl.path)/help" class="">http://apple.com\(originalURL.path)/help</a>")</div><div class=""><br class=""></div><div class="">What's the newURL? Nil, because it was being inited with</div><div class=""><br class=""></div><div class=""><a href="http://apple.comoptional(/iphone)/help" class="">http://apple.comOptional(/iphone)/help</a></div><div class=""><br class=""></div><div class="">Since the path property is optional.</div><div class=""><br class=""></div><div class="">Which is not something you figure out until runtime, wondering why the URL is nil. This is very annoying when you run into this issue repeatedly on several occasions because you forget to unwrap the value.</div><div class=""><br class=""></div><div class="">*This* is IMHO an undesired and unexpected behavior.</div><div class=""><br class=""></div><div class="">If interpolating optionals did become a warning, you'd immediately know about a potential bug: you don't check if path != nil.</div><div class=""><br class=""></div><div class="">BTW if you still want the original behavior of printing </div><div class=""><br class=""></div><div class="">Optional(my string value),</div><div class=""><br class=""></div><div class="">you can still write </div><div class=""><br class=""></div><div class="">"<a href="http://apple.com\(originalurl.path.debugdescription)/help" class="">http://apple.com\(originalURL.path.debugDescription)/help</a>" </div><div class=""><br class=""></div><div class="">which invokes debugDescription on the Optional, not the String (since there is no "?"), and you get the original value anyway. And this could be the Fix-It for it as well to maintain original behavior.</div><div class=""><br class=""></div><div class="">Krystof</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 19, 2016, at 9:28 AM, Dan Appel <<a href="mailto:dan.appel00@gmail.com" class="">dan.appel00@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">You know what's worse than seeing "Optional(my string value)" in a label? Seeing "nil". When the optional is there, it is made clear to the developer that the string they are showing <i class="">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 "nil". 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 class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, May 19, 2016 at 12:24 AM David Waite <<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>> wrote:<br class=""></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" class=""><div class="">Making string interpolation reject just optional (at compile time) when it doesn’t reject any other type sounds tricky to express.</div><div class=""><br class=""></div><div class="">What if instead Optional just didn’t decorate the wrapped value, outputting either the inner value or “nil” in these cases?</div><div class=""><br class=""></div><div class="">The debugDescription could remain "Optional(data)" style.</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">-DW</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 19, 2016, at 12:52 AM, Valentin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class="">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't see this mistake until much later at runtime.</div><div class="">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 class=""><br class="">On 19 mai 2016, at 00:56, Dan Appel via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">-1. <br class=""><br class="">Optional(foo) better depicts the actual type (it's an options string, after all). If you're not happy with it, just use the nil coalescing operator such as "\(foo ?? "")". This is from the same series of proposals as implicit casting - there are reasons it's done the way it is.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">+1, personally I have taken to using `x+"str"+y` instead of `"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I do this accidentally.</div><div class=""><br class=""></div><div class="">But I do see the appeal of being able to print("the data: \(data)") for simple use cases. Didn't someone earlier propose some modifiers/labels like "\(describing: x)" ?</div></div><div dir="ltr" class=""><div class="gmail_extra"><div class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Wed, May 18, 2016 at 11:50 AM, Krystof Vasa via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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 class="">
<br class="">
It has happened to me more than once that I've used the interpolation with an optional by mistake and the result is then far from the expected result.<br class="">
<br class="">
This happened mostly before Swift 2.0's guard expression, but has happened since as well.<br class="">
<br class="">
The user will seldomly want to really get the output "Optional(something)", but is almost always expecting just "something". 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's almost always better to use the ?? operator and supply a null value placeholder, e.g. "\(myOptional ?? "<<none>>")", or use myOptional.debugDescription - which is a valid expression that will always return a non-optional value to force the current behavior.<br class="">
<br class="">
Krystof<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div><br class=""></div></div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div><div dir="ltr" class="">-- <br class=""></div><div dir="ltr" class=""><div class=""><div class="">Dan Appel<br class=""></div></div></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><div dir="ltr" class="">-- <br class=""></div><div class=""><div dir="ltr" class=""><div class=""><div class="">Dan Appel<br class=""></div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>