73

Why are implicitly unwrapped optionals not unwrapped when using string interpolation in Swift 3?

Example: Running the following code in the playground

var str: String!
str = "Hello"

print("The following should not be printed as an optional: \(str)")

produces this output:

The following should not be printed as an optional: Optional("Hello")

Of course I can concatenate strings with the + operator but I'm using string interpolation pretty much everywhere in my app which now doesn't work anymore due to this (bug?).

Is this even a bug or did they intentionally change this behaviour with Swift 3?

Keiwan
  • 8,031
  • 5
  • 36
  • 49
  • 4
    Note that this will soon produce a warning: https://github.com/apple/swift/pull/5110 – jtbandes Dec 04 '16 at 09:26
  • 1
    This is the cleanest solution in my opinion and it's better because it explicitly says what happens when `str` is `nil`: `print("The following should not be printed as an optional: \(str ?? "")")` – hashemi Dec 05 '16 at 19:33
  • 2
    @hashemi The core issue here is that this should not be necessary at all. The whole point of an IUO is that you know that it will always have a value when it's being accessed and therefore you don't need to perform an explicit `nil` check. Also - as the name suggests - the compiler is supposed to do all the unwrapping for you, but it doesn't. – Keiwan Dec 05 '16 at 20:18
  • Ole Begemann on optionals & string interpolation in 3.0 and 3.1 (not on IUOs specifically though) https://oleb.net/blog/2016/12/optionals-string-interpolation/ – hashemi Dec 08 '16 at 11:25
  • Hi Keiwan, you just have to put ! next to your string variable in the print statement like this, print("The following should not be printed as an optional: \(str!)") – Nand Parikh Jan 06 '17 at 06:32

1 Answers1

71

As per SE-0054, ImplicitlyUnwrappedOptional<T> is no longer a distinct type; there is only Optional<T> now.

Declarations are still allowed to be annotated as implicitly unwrapped optionals T!, but doing so just adds a hidden attribute to inform the compiler that their value may be force unwrapped in contexts that demand their unwrapped type T; their actual type is now T?.

So you can think of this declaration:

var str: String!

as actually looking like this:

@_implicitlyUnwrapped // this attribute name is fictitious 
var str: String?

Only the compiler sees this @_implicitlyUnwrapped attribute, but what it allows for is the implicit unwrapping of str's value in contexts that demand a String (its unwrapped type):

// `str` cannot be type-checked as a strong optional, so the compiler will
// implicitly force unwrap it (causing a crash in this case)
let x: String = str

// We're accessing a member on the unwrapped type of `str`, so it'll also be
// implicitly force unwrapped here
print(str.count)

But in all other cases where str can be type-checked as a strong optional, it will be:

// `x` is inferred to be a `String?` (because we really are assigning a `String?`)
let x = str 

let y: Any = str // `str` is implicitly coerced from `String?` to `Any`

print(str) // Same as the previous example, as `print` takes an `Any` parameter.

And the compiler will always prefer treating it as such over force unwrapping.

As the proposal says (emphasis mine):

If the expression can be explicitly type checked with a strong optional type, it will be. However, the type checker will fall back to forcing the optional if necessary. The effect of this behavior is that the result of any expression that refers to a value declared as T! will either have type T or type T?.

When it comes to string interpolation, under the hood the compiler uses this initialiser from the _ExpressibleByStringInterpolation protocol in order to evaluate a string interpolation segment:

/// Creates an instance containing the appropriate representation for the
/// given value.
///
/// Do not call this initializer directly. It is used by the compiler for
/// each string interpolation segment when you use string interpolation. For
/// example:
///
///     let s = "\(5) x \(2) = \(5 * 2)"
///     print(s)
///     // Prints "5 x 2 = 10"
///
/// This initializer is called five times when processing the string literal
/// in the example above; once each for the following: the integer `5`, the
/// string `" x "`, the integer `2`, the string `" = "`, and the result of
/// the expression `5 * 2`.
///
/// - Parameter expr: The expression to represent.
init<T>(stringInterpolationSegment expr: T)

Therefore when implicitly called by your code:

var str: String!
str = "Hello"

print("The following should not be printed as an optional: \(str)")

As str's actual type is String?, by default that's what the compiler will infer the generic placeholder T to be. Therefore the value of str won't be force unwrapped, and you'll end up seeing the description for an optional.

If you wish for an IUO to be force unwrapped when used in string interpolation, you can simply use the force unwrap operator !:

var str: String!
str = "Hello"

print("The following should not be printed as an optional: \(str!)")

or you can coerce to its non-optional type (in this case String) in order to force the compiler to implicitly force unwrap it for you:

print("The following should not be printed as an optional: \(str as String)")

both of which, of course, will crash if str is nil.

Hamish
  • 78,605
  • 19
  • 187
  • 280
  • 29
    As if it weren't bad enough that you have to use an IUO, now they're less useful and behave contradictorily. If I use one it's because I want it to be implicitly unwrapped. They should be called Schrödinger Optionals from now on. – Andreas Oct 30 '16 at 21:08
  • 5
    Just don't use them. – Alexander Nov 30 '16 at 20:00
  • 6
    The explanation given is great. The fact that this explanation needs to be given is not. The more I work with Swift, the more I am under the impression that they simply replaced one type of complexity from objc with another type, and that in the end, it's just as hard/wasy to use one or the other. How this kind of stuff should make programmer's lives easier is beyond me. – Joris Mans Dec 17 '16 at 14:24
  • Between this kind of stuff and the amount of love they give to Swift support in XCode its hard to believe that this is the language Apple is pushing us to use – la_f0ka Mar 09 '17 at 09:57
  • 6
    While i am unexpectedly loving Swift as compared to Obj-C, i must admit that seemingly 75% of my coding efforts directly or indirectly involve correcting optional variable requirements. It is a stunning amount of effort for what is a simple enough issue: is an object nil or not? Surely there must have been better options (pun intended). – drew.. Sep 08 '17 at 17:20
  • Coming from a JS/PHP background, I never realized how spoiled I was dealing with variable types :O Of course those languages have their _own_ problems ;) – Robert Dundon Mar 06 '18 at 18:29
  • But why does the implicit unwrapping has stopped only in case of String data types? In my dictionary, if I have 2 parameters: one Int! type and other String! type, the Int! type is unwrapped but String! type comes as some("myValue"). – crypt Jul 09 '18 at 11:14
  • @crypt They should behave consistently AFAIK – could you please provide a bit more context about your dictionary and how you're adding the IUO values to it? Note that you'll get different results from using the value in a literal vs. assigning through the dictionary subscript, compare https://stackoverflow.com/q/50051964/2976878 – Hamish Jul 14 '18 at 16:07
  • @Hamish Yes you are right. There is no inconsistency. It works as you have described. Thanks. – crypt Jul 20 '18 at 11:33