> On May 19, 2016, at 11:01 PM, Krystof Vasa via swift-evolution > <swift-evolution@swift.org> wrote: > > With this proposal in place: > > 1) The user would type print(myURL.path). > 2) The compiler will immediately issue a warning about printing an optional - > the user would hence learn about optionals *before* the code is run. > 3) If he ran the code anyway, he'd still get Optional(/iphone/) anyway. > 4) Xcode would offer a Fix-It, adding .debugDescription to the optional, > getting Optional(/iphone/) on the anyway, yet again.
Four questions: 1. If I was printing a protocol type that Optional supports, such as Any, would I get a warning? 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. 3. How would I have the ability to opt into this behavior for my own types (such as Result or Future)? 4. How would I opt in/out of this behavior for my own StringInterpolationConvertible implementations? -DW > > 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. > >> On May 20, 2016, at 6:48 AM, Dan Appel via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >google for swift print optional stackoverflow. I think that kind of speaks >> >for itself. >> >> I think this is actually an example of why the current behavior is a good >> 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. >> >> On Thu, May 19, 2016 at 9:36 PM Krystof Vasa via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> BTW - google for swift print optional stackoverflow. I think that kind of >> speaks for itself. >> >> > On May 19, 2016, at 6:07 PM, Jeremy Pereira via swift-evolution >> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > >> > -1 >> > >> > 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. >> > >> >> On 18 May 2016, at 19:50, 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 >> >> <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 >> > <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 >> <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
