I think displaying a warning instead of deprecation would suffice. A down vote for deprecation.
On 19 May 2016, 4:06 PM +0800, Patrick Smith via swift-evolution<swift-evolution@swift.org>, wrote: > 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(http://apple.com/(originalurl.path?)/help)” > > This would be compatible withStringInterpolationConvertible, 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<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote: > > Consider the following example: > > > > let originalURL: NSURL = NSURL(string: "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<dan.appe...@gmail.com(mailto:dan.appe...@gmail.com)>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 showingcan 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<da...@alkaline-solutions.com(mailto:da...@alkaline-solutions.com)>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<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>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<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>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<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>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<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>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 > > > > > > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > > > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > > > > > > > > _______________________________________________ > > > > > > > swift-evolution mailing list > > > > > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > -- > > > > > > Dan Appel > > > > > > _______________________________________________ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > _______________________________________________ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > -- > > > Dan Appel > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
