[swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Mark Lacey]

> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution <swift-evolution at 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 at swift.org <mailto:swift-evolution at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161004/64fd9ec8/attachment.html>