On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard <ke...@sb.org> wrote: > 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-evolution@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-evolution@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-evolution@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. >
Agreed, but I thought that's what you were asking for above? > > > -Kevin >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution