<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=""><div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Four questions:</div></div><div class="">1. If I was printing a protocol type that Optional supports, such as Any, would I get a warning?</div></div></blockquote><div><br class=""></div><div>This was my bad, I wrote an incorrect example, print("<a href="http://apple.com\(myurl.path)" class="">http://apple.com\(myURL.path)</a>") was what I meant - which will print </div><div><br class=""></div><div><a href="http://apple.comoptional(/iphone/)" class="">http://apple.comOptional(/iphone/)</a>. </div><div><br class=""></div><div>Putting an optional directly into print(_:) should be fine with no warning. Only within the string interpolation.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">2. I believe debugDescription is discouraged from being called directly [from CustomDebugStringConvertible docs]. Perhaps String(reflecting: ) instead, although such debug description behavior could cause different results if you were expecting this fixit to apply to Any types.</div></div></blockquote><div><br class=""></div><div>This is not invoked on the value within the Optional, but directly *on* the Optional. As declared here (part of Swift):</div><div><br class=""></div><div>extension Optional : CustomDebugStringConvertible {<br class=""> /// A textual representation of `self`, suitable for debugging.<br class=""> public var debugDescription: String { get }<br class="">}</div><div><br class=""></div><div>Example:</div><div><br class=""></div><div>let stringOptional: String? = "Hello"</div><div><br class=""></div><div>// Notice no ? is used - the optional is not unwrapped</div><div>stringOptional.debugDescription // Optional(Hello)</div><div><br class=""></div><div>// Unwrapping the optional</div><div>stringOptional!.debugDescription // Hello</div><div><br class=""></div><div><div>Not sure what would be the impact of making Optional CustomStringConvertible (i.e. instead of using debugDescription, one would use just description).</div></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">3. How would I have the ability to opt into this behavior for my own types (such as Result or Future)?</div><div class="">4. How would I opt in/out of this behavior for my own StringInterpolationConvertible implementations?</div></div></blockquote><div><br class=""></div><div>This is not about customizing the interpolation but about warning the user when using optionals in string interpolation to prevent from such mistakes as above with the URL. This is more common than one would think and sometimes is hard to spot. I'm sorry if I misunderstood you questions.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I'm not saying *removing* the current behavior, but adding a warning for this - you'd get the same result ignoring the warning and applying the Fix-It, but you'd have control over this.</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On May 20, 2016, at 6:48 AM, Dan Appel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">>google for swift print optional stackoverflow. I think that kind of speaks for itself.<div class=""><br class=""><div dir="ltr" class=""><div class="">I think this is actually an example of why the current behavior is a <i class="">good</i> thing. I did just google that and the top comment of the first result explains what an optional is. That is very good and encourages beginners to understand how optionals work under the hood. If you hide that from them, they will only be even more confused when they see just the string "nil" pop up when it previously was showing the correct value.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, May 19, 2016 at 9:36 PM Krystof Vasa 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">BTW - google for swift print optional stackoverflow. I think that kind of speaks for itself.<br class="">
<br class="">
> On May 19, 2016, at 6:07 PM, Jeremy Pereira via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> -1<br class="">
><br class="">
> This seems to me like crippling string interpolation just because sometimes we make mistakes. 99% of the time, if I interpolate an optional, it’s because I want it that way. I don’t want to have to put up with a warning or write the same boilerplate 99% of the time just to flag up the 1% more easily. Sorry.<br class="">
><br class="">
>> On 18 May 2016, at 19:50, Krystof Vasa via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> 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="">
><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="">
<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></div></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>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></body></html>