PrePitch: Optional variables should require explicit initialization

To Elaborate on some of @clayellis's points, it seems relevant to bring up some of the purpose of Optionals.

This is obviously not new information, but one purpose is giving users a way to easily guarantee runtime safety at compile time. It requires being explicit about whether a value is required or can have no value. If something is declared as Optional, having no value is a valid state and has a very specific runtime meaning.

So if this seems like a special case, that's because it is. Things like empty Arrays or Strings have no specific meaning to the compiler or runtime. .none does.

One thing that hasn't really been brought up is the amount of flexibility and brevity implicit .none gives. E.g. subclasses not having to initialized as many properties in their custom initializers.

Previous domains should also probably be mentioned. Class @propertys in Objective-C are implicitly nil, so having similar behavior in Swift helps with knowledge transfer, as well as converting/interfacing-with existing legacy code.


For iOS development, this is really not a safe assumption. Also, is this a pattern we want to go support, where we ignore the lazy loading aspects of the nib system just for developer convenience?

I’ve seen far too many bugs due to these assumptions. Young devs are encouraged enough to ignore nib loading behavior, lets not make it worse by making the language actively lie to the engineer...

Unfortunately "Safe" is not really a term associated Interface Builder :disappointed:



I like it the way things are. Requiring assignment to nil for optional ivars would just be extra noise with little or no gain in clarity. I like the way swiftlint tells me to not do it.


I'm very much +1 on this. Had a thread on this containing some of the pitfalls of implicit initialization with nil a while back: Remove implicit initialization of Optionals?

I missed this other one too.

I’m leaning towards proposing something along the lines of default initialization via property wrappers.

@Default var foo:String // initialized to “”
@Default var foo2: String? // initialized to .some(String())

This would be counterintuitive given that for the past 5 years, var foo2: String? is nil by default.

1 Like

@Default var foo2: String? // initialized to .some(String())

Would be equivalent to

var foo2: String? // = nil
foo2 = String() // optional promotion is another can of worms. 
print(foo2) // .some("")

Just to be clear, are you proposing @Default instead of the proposed change to require explicitly declaring = nil or alongside it?


I think at least some form of this proposal should be put up for review specially for the tuple case which is just bizarre. I will start another thread about the @Default. Thanks for the question!

Good to know. And yeah, I'd agree, that case is pretty odd. I'd be curious to know if anyone is actually using that as a "feature"

No sure but its an old bug report.

Definetly -1, I dont like the idea to add useless code to make explicit an intuitive default

It’s ok to both like and prefer the current implementation, but to call it useless is factually incorrect. Explicit initialization can prevent real bugs, and there is a real semantic difference between uninitialized and nil. There are real, measurable use cases.

Please refrain from stating opinions as fact.

What you mean to say, is that you don’t care much about that difference and that the convenience of implicit initialization far outweighs the costs. Which is a fine position to have. But it doesn’t make the suggested change “useless”.


To be honest, I don't have a single opinion here. If you were to default initialize a value, nil is the most appropriate concept to use. I could even see a case for this to be expanded to encompass all types supporting ExpressibleByNilLiteral, rather than being tied to the ? and ! shortcuts for Optionals.

I do think a rule change around properties needs to take into account lazy properties and property wrappers, both of which also change the perceived behavior of initialization.

Sure, the default is intuitive, but it's inconsistent. Why should sugared optionals be implicitly initialized when nothing else is? Not even Optional<T> which is supposed to be the same thing.


I can see a case for requiring explicit nil for (?) Optionals. For (!) IUOs it would seem very counter intuitive to have to explicitly set them to nil at init time since their semantic purpose is deferred initialization.


For reasons laid out higher up in the discussion.

I’m -1 on this. In my opinion implicitly initializing optionals to nil is intuitive for experienced programmers and beginners.

A lot of my code as well as other code I have seen relies on this feature and removing it would cause a lot of code churn.