[swift-evolution] Proposal: Deprecate optionals in string interpolation

[Dan Appel]

You know what's worse than seeing "Optional(my string value)" in a label?
Seeing "nil". When the optional is there, it is made clear to the developer
that the string they are showing *can be nil*. However, if you hide that
from the users you are less likely to unwrap that optional and hence more
likely to show the user "nil". This behavior really goes against some of
the core ideas of Swift - you want your code to be expressive but not
abstract away potentially useful information.

On Thu, May 19, 2016 at 12:24 AM David Waite <david at alkaline-solutions.com>
wrote:

> Making string interpolation reject just optional (at compile time) when it
> doesn’t reject any other type sounds tricky to express.
>
> What if instead Optional just didn’t decorate the wrapped value,
> outputting either the inner value or “nil” in these cases?
>
> The debugDescription could remain "Optional(data)" style.
>
> -DW
>
> On May 19, 2016, at 12:52 AM, Valentin via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> From what I understand of this thread, the argument here is that directly
> using an optional in a string interpolation is almost never what you really
> want to do (except mainly for debugging purposes) but you wouldn't see this
> mistake until much later at runtime.
> And I feel like one of Swift goals is to enable us, imperfect human
> creatures, to detect as many problems or mistakes as possible long before
> runtime.
>
> On 19 mai 2016, at 00:56, Dan Appel via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> -1.
>
> Optional(foo) better depicts the actual type (it's an options string,
> after all). If you're not happy with it, just use the nil coalescing
> operator such as "\(foo ?? "")". This is from the same series of proposals
> as implicit casting - there are reasons it's done the way it is.
> On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> +1, personally I have taken to using `x+"str"+y` instead of
>> `"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I
>> do this accidentally.
>>
>> But I do see the appeal of being able to print("the data: \(data)") for
>> simple use cases. Didn't someone earlier propose some modifiers/labels like
>> "\(describing: x)" ?
>>
>>
>> On Wed, May 18, 2016 at 11:50 AM, Krystof Vasa via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> The string interpolation is one of the strong sides of Swift, but also
>>> one of its weaknesses.
>>>
>>> It has happened to me more than once that I've used the interpolation
>>> with an optional by mistake and the result is then far from the expected
>>> result.
>>>
>>> This happened mostly before Swift 2.0's guard expression, but has
>>> happened since as well.
>>>
>>> The user will seldomly want to really get the output
>>> "Optional(something)", but is almost always expecting just "something". I
>>> believe this should be addressed by a warning to force the user to check
>>> the expression to prevent unwanted results. If you indeed want the output
>>> of an optional, it's almost always better to use the ?? operator and supply
>>> a null value placeholder, e.g. "\(myOptional ?? "<<none>>")", or use
>>> myOptional.debugDescription - which is a valid expression that will always
>>> return a non-optional value to force the current behavior.
>>>
>>> Krystof
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Dan Appel
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160519/d9f30827/attachment.html>