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

[Dan Appel]

Actually, I just noticed the comment about never wanting to show an
optional value. That is a fair point, and worthy of consideration. I'm
happy as long as there is no surprising behavior going on :)

On Thu, May 19, 2016 at 12:28 AM Dan Appel <dan.appel00 at gmail.com> wrote:

> 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
>
-- 
Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160519/e04f9a88/attachment.html>