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