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

[Xiaodi Wu]

On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard <kevin at 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 at 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 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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161004/bc65a7a4/attachment.html>