Actually, I just noticed the comment about never wanting to show an optional value. That is a fair point, and worthy of consideration. I'm happy as long as there is no surprising behavior going on :)
On Thu, May 19, 2016 at 12:28 AM Dan Appel <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 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 <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> 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> 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> 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> 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 >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> -- >> Dan Appel >> >> _______________________________________________ >> 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 >> >> >> -- > Dan Appel > -- Dan Appel
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution