# Remove implicit initialization of Optionals?

**URL:** <https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482>\
**Category:** Pitches\
**Tags:** init, optional\
**Created:** [January 13, 2019, 8:40pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482 "2019-01-13T20:40:50Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![jenox](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jenox/32/5811_2.png) [@jenox](https://forums.swift.org/u/jenox)\
**Post date:** [January 13, 2019, 8:40pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482/1 "2019-01-13T20:40:51Z")

</div>

The compiler currently warns us if we try to use a constant before it is initialized on all paths through the program:

```swift
let x: Int
print(x) // Error: "Constant 'x' used before being initialized"

```

The same thing happens for non-optional variables:

```swift
var x: Int
print(x) // Error: "Variable 'x' used before being initialized"

```

Optional variables and implicitly unwrapped Optionals, however, seem to be silently initialized with `.none` and can be used before assigning another value to it. The following snippet compiles just fine:

```swift
var x: Int?
print(x) // prints "nil"

```

* * *

I think that the default initialization of Optionals is potentially dangerous, as it makes it possible to forget to initialize an Optional with a proper value on some paths:

```swift
var x: Int?
if f() {
    x = 5
} else {
    // forgot to initialize x
}
print(x)

```

Similarly, it makes it possible to forget to initialize stored properties in a struct or class:

```swift
struct X {
    init() {
        // forgot to initialize self.x
    }
    var x: Int?
}

```

The latter becomes especially painful when adding new stored properties to a type that has a lot of initializers — it is super easy to forget initializing the property in one of them.

* * *

Personally I don't think there's a reason to implicitly initialize Optionals with `.none` and treat them any differently than non-optional variables or constants, especially since we can't turn that behavior off. And if that's what we desire, it would be as simple as adding a ` = nil` to the declaration.

What do you guys think about removing the default initialization with `.none` of Optionals?

---

<div class="post-metadata">

**Author:** ![Alejandro](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro/32/46197_2.png) [@Alejandro](https://forums.swift.org/u/Alejandro)\
**Post date:** [January 13, 2019, 9:05pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482/2 "2019-01-13T21:05:24Z")

</div>

For reference this has been brought up before: [Pitch: Remove default initialization of optional bindings](https://forums.swift.org/t/pitch-remove-default-initialization-of-optional-bindings/6961)

---

<div class="post-metadata">

**Author:** ![jenox](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jenox/32/5811_2.png) [@jenox](https://forums.swift.org/u/jenox)\
**Post date:** [January 15, 2019, 1:37pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482/3 "2019-01-15T13:37:24Z")

</div>

Thanks for pointing this out, Alejandro.

However, the discussion in the thread you linked was mostly about personal preference — the potential pitfalls I mentioned in my post were not brought up back there and are the primary reason I would like to see this change.

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [January 15, 2019, 3:35pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482/4 "2019-01-15T15:35:07Z")

</div>

I think for that the ship has sailed because there is too much code out in the wild that relies on that feature especially in context of type properties. Removing it now would end up in a catastrophic source breaking change.

---

<div class="post-metadata">

**Author:** ![jenox](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jenox/32/5811_2.png) [@jenox](https://forums.swift.org/u/jenox)\
**Post date:** [January 15, 2019, 3:37pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482/5 "2019-01-15T15:37:08Z")

</div>

It would indeed be a source-breaking change, but one with a trivial fix: the migrator could simply add `= nil` to all declarations of optional variables.

---

<div class="post-metadata">

**Author:** ![nuclearace](https://avatars.discourse-cdn.com/v4/letter/n/51bf81/32.png) [@nuclearace](https://forums.swift.org/u/nuclearace)\
**Post date:** [January 15, 2019, 3:51pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482/6 "2019-01-15T15:51:11Z")

</div>

In my experience, this behavior isn't actively harmful. I can remember maybe 2 times where I've had bugs because I failed to assign back to the variable, and both of those cases were caught almost immediately by testing.

As for the initializer issue, I would say that if you have so many initializers that forgetting to update one is an issue for you, I'd say you have too many initializers. And again, this type of bug should be caught by your unit testing

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [January 15, 2019, 3:56pm UTC](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482/7 "2019-01-15T15:56:43Z")

</div>

The case where I think it is most likely to lead to problems is with IUO. I have long wanted a mechanism similar to IUO, but which requires assignment to a non-nil value during phase 2 of initialization and can never be set to a nil value after initialization (with the option to become immutable after initialization is complete). Something like that would remove most of the danger of implicit initialization to nil.