PrePitch: Optional variables should require explicit initialization

Evolution Pitches
82

I think you misunderstand this proposal. It would make no change and have no effect on the code example you posted above.

83

let optional: Int? has never received default nil initialization because if they did, you couldn't change their value because they're constants. @sveinhal is correct in saying that you wouldn't receive a warning whether optional was a let or a var.

struct Thing {
  let field: Int
  let optional: Int? // no warning here
  var optional2: Int? // still no warning here
}

You would still receive the same memberwise initializer where you would initialize both optionals.

3 Likes
84

I mean that let already work in accordance to this proposal. This only proposes to make var work the same with regards to initialization.

The gain would be correctness and help from the compiler to avoid subtle and hard to find bugs. It would have no effect on the synthesized memberwise init, the Decodable init or anything like that.

But it would make it an error (or warning) to not initialize optional vars in your own inits.

3 Likes
85

Sorry, I've never noticed that difference before.

86

It is unclear to me what the going forward process is for these types of enhancements. It would seem to me that the core team needs to decide how to handle these kind of improvements that could potentially have a very long deprecation period.

3 Likes
87

+1

88

+/- 0.

Why can't we just compromise and have a compiler flag to enable a warning? Does it have to be one way or the other?

2 Likes
89

+1 Let’s push for the flag.

2 Likes
90

Yes, it does. It is an intentional design choice that there should not be “dialects” of Swift (with the exception of older language versions and library resiliency mode, unavoidable for obvious reasons).

Therefore, with the exception of language mode and resiliency, Swift flags do not change what does and doesn’t compile, and Swift doesn’t have optional warnings.

9 Likes