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

Thu May 19 06:26:08 CDT 2016

Strong +1 for the (at least) warning in case of optional in string 
interpolation.

Actually I think `Optional(something)` is a form of text representation for 
*debugging only*, not for 'production'. It is clear, that by default we 
need text representation for 'production', so it is logical for me that 
optional in string interpolation should return text without `Optional(..)`. 
Probably this means that optional should not have default .description for 
`production`, but just debugDescription for debugging.

So, for production you'll need to have:

let newURL = NSURL(string: "http://apple.com\(originalURL.path!)/help")
(or use ?? etc)

for debugging:
let newURL = NSURL(string: 
"http://apple.com\(originalURL.path.debugDescription)/help")

On 19.05.2016 10:39, Krystof Vasa via swift-evolution wrote:
> Consider the following example:
>
> let originalURL: NSURL = NSURL(string: "http://apple.com/iphone")!
> let newURL = NSURL(string: "http://apple.com\(originalURL.path)/help")
>
> What's the newURL? Nil, because it was being inited with
>
> http://apple.comOptional(/iphone)/help
> <http://apple.comoptional%28/iphone%29/help>
>
> Since the path property is optional.
>
> Which is not something you figure out until runtime, wondering why the URL
> is nil. This is very annoying when you run into this issue repeatedly on
> several occasions because you forget to unwrap the value.
>
> *This* is IMHO an undesired and unexpected behavior.
>
> If interpolating optionals did become a warning, you'd immediately know
> about a potential bug: you don't check if path != nil.
>
> BTW if you still want the original behavior of printing
>
> Optional(my string value),
>
> you can still write
>
> "http://apple.com\(originalURL.path.debugDescription)/help"
>
> which invokes debugDescription on the Optional, not the String (since there
> is no "?"), and you get the original value anyway. And this could be the
> Fix-It for it as well to maintain original behavior.
>
> Krystof
>
>> On May 19, 2016, at 9:28 AM, Dan Appel <dan.appel00 at gmail.com
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>>>     <mailto: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
>>>>         <mailto: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 <mailto:swift-evolution at swift.org>
>>>>             https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>>         _______________________________________________
>>>>         swift-evolution mailing list
>>>>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>         https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>     --
>>>>     Dan Appel
>>>>     _______________________________________________
>>>>     swift-evolution mailing list
>>>>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>>     _______________________________________________
>>>     swift-evolution mailing list
>>>     swift-evolution at swift.org <mailto: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
>