> 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 <mailto: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? Mark
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
