On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote: > On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution <swift- > evolut...@swift.org> wrote: >> __ >> >> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: >>> >>>> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution <swift- >>>> evolut...@swift.org> wrote: >>>> >>>> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote: >>>>>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution <swift- >>>>>> evolut...@swift.org> wrote: >>>>>> >>>>>> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote: >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>> We had this at one point, but we took it out because people >>>>>>> would forget to test the nil case. I think `?? ""` or `?? nil` >>>>>>> really is the best answer here. >>>>>> >>>>>> But you can't write that, unless you're dealing specifically with >>>>>> an Optional<String>. If you try you'll get an error: >>>>>> >>>>>> unnamed.swift:2:19: error: binary operator '??' cannot be applied >>>>>> to operands of type 'Int?' and 'String' >>>>>> print("x: \(x ?? "nil")") >>>>>> ~ ^ ~~~~~ >>>>>> unnamed.swift:2:19: note: overloads for '??' exist with these >>>>>> partially matching parameter lists: (T?, @autoclosure () throws >>>>>> -> T), (T?, @autoclosure () thro >>>>>> ws -> T?) >>>>>> print("x: \(x ?? "nil")") >>>>>> ^ >>>>>> This leads to writing code like "… >>>>>> \(x.map(String.init(describing:)) ?? "nil")" which is pretty >>>>>> gross. >>>>> >>>>> I think that if we're going to add this warning we should make it >>>>> possible to provide a string as an alternative. It seems like it >>>>> should be possible to build a ?? operator with a (T?, String) -> >>>>> _StringInterpolationSomething signature that works only in a >>>>> string interpolation context. >>>>> >>>>> There are some types that aren't trivially constructible, or don't >>>>> have clear alternatives for the nil case. Other times it might >>>>> just not make sense to build a new instance simply to turn it into >>>>> a string. If we're going to make people provide an alternative for >>>>> optionals in this otherwise simple-to-use construct, let's make it >>>>> simple to do so. >>>>> >>>>> This is undoubtedly a more complex approach that could be >>>>> considered separately, but I think it would be a valuable part of >>>>> how developers could transition their code. >>> >>> That’s definitely more complex, and seems like a completely >>> orthogonal feature request. >>> >>>>> >>>> I like this idea. This combined with the warning for naively >>>> interpolating an Optional would be a good solution, because now >>>> when I see the warning I can trivially solve it with `?? "nil”`. >>> >>> If you can suppress the warning with `as T?` (where T? is the type >>> of the thing being warned on), you wouldn’t need a form that >>> specifically printed “nil”, correct? >> >> >> How many times do I need to repeat myself? I'm looking for a solution >> to the problem where printing Optionals sanely (e.g. no "Optional(…)" >> wrapper for .some values) is a PITA right now. Getting rid of the >> warning does not solve this problem. This is why I like Nate Cook's >> idea to enable `?? "nil"` in string interpolations, because it *does* >> solve my problem. And with this tool, now the warning on printing >> Optionals becomes useful because it tells me where to add `?? "nil"`. >> Getting rid of the warning without the ability to add `?? "nil"` is >> not helpful to me, because I don't want to print "Optional(…)". > > I'm confused. Why not just add this to your project? > > ``` > extension Optional : CustomStringConvertible { > public var description: String { > guard let some = self else { return "nil" } > return String(describing: some) > } > } > ```
Because that's globally changing the behavior of Optional in a way that's very surprising. -Kevin
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution