Yes, I think I agree this should show a warning, and require you to explicitly state that you are happy dealing with an optional.
Possibly you would have to add a ? suffix to make it explicit: "http://apple.com\(originalURL.path?)/help” This would be compatible with StringInterpolationConvertible, where you may still want the original optional passed, whereas `.debugDescription` would always pass a string. > On 19 May 2016, at 5:39 PM, Krystof Vasa via swift-evolution > <[email protected]> wrote: > > Consider the following example: > > let originalURL: NSURL = NSURL(string: "http://apple.com/iphone > <http://apple.com/iphone>")! > let newURL = NSURL(string: "http://apple.com\(originalURL.path)/help > <http://apple.com/(originalurl.path)/help>") > > What's the newURL? Nil, because it was being inited with > > http://apple.comOptional(/iphone)/help > <http://apple.comoptional(/iphone)/help> > > Since the path property is optional. > > 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. > > *This* is IMHO an undesired and unexpected behavior. > > If interpolating optionals did become a warning, you'd immediately know about > a potential bug: you don't check if path != nil. > > BTW if you still want the original behavior of printing > > Optional(my string value), > > you can still write > > "http://apple.com\(originalURL.path.debugDescription)/help > <http://apple.com/(originalurl.path.debugdescription)/help>" > > 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. > > Krystof > >> On May 19, 2016, at 9:28 AM, Dan Appel <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 can be nil. 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. >> >> On Thu, May 19, 2016 at 12:24 AM David Waite <[email protected] >> <mailto:[email protected]>> wrote: >> Making string interpolation reject just optional (at compile time) when it >> doesn’t reject any other type sounds tricky to express. >> >> What if instead Optional just didn’t decorate the wrapped value, outputting >> either the inner value or “nil” in these cases? >> >> The debugDescription could remain "Optional(data)" style. >> >> -DW >> >>> On May 19, 2016, at 12:52 AM, Valentin via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> 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. >>> 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. >>> >>> On 19 mai 2016, at 00:56, Dan Appel via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> -1. >>>> >>>> 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. >>>> On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> +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. >>>> >>>> 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)" ? >>>> >>>> >>>> On Wed, May 18, 2016 at 11:50 AM, Krystof Vasa via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> The string interpolation is one of the strong sides of Swift, but also one >>>> of its weaknesses. >>>> >>>> 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. >>>> >>>> This happened mostly before Swift 2.0's guard expression, but has happened >>>> since as well. >>>> >>>> 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. >>>> >>>> Krystof >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> -- >>>> Dan Appel >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> -- >> Dan Appel > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
