Rule Request: Inverting redundant_optional_initialization

[Uncommon]

Proposal: add an "inverted" configuration option to the existing redundant_optional_initialization rule, so that initializing variables with nil is required rather than disallowed.

Also, I have found that variables declared as Optional<Type> rather than Type? are not implicitly initialized to nil. The rule as currently implemented assumes that they are, so I intend to fix that while I'm at it.

New Issue Checklist

• [x] Updated SwiftLint to the latest version
• [x] I searched for existing GitHub issues

New rule request

Please describe the rule idea, format this issue's title as Rule Request: [Rule Name] and describe:

1. Why should this rule be added? Share links to existing discussion about what the community thinks about this.

Inspired by this discussion in the Swift forums: https://forums.swift.org/t/prepitch-optional-variables-should-require-explicit-initialization-to-nil/26077

2. Provide several examples of what would and wouldn't trigger violations.

The reverse of the examples for the existing rule.

3. Should the rule be configurable, if so what parameters should be configurable?

Setting inverted: true would treat the absence, rather than presence, of = nil as a violation.

4. Should the rule be opt-in or enabled by default? Why?

The inverted configuration should default to false to preserve existing behavior.

[samrayner]

Related to this, Swift 5.1 propertyWrappers require explicit initialisation too:

@State private var errorModal: Modal? = nil

While you're handling the Optional<Type> case I don't suppose you could handle this too please?

[jshier]

Related to this, Swift 5.1 propertyWrappers require explicit initialisation too:

@State private var errorModal: Modal? = nil

While you're handling the Optional<Type> case I don't suppose you could handle this too please?

I believe this is just a bug in the implementation of property wrappers and is intended to be fixed.

[markgravity]

I need it !!

[rakuyoMo]

I need this too, and I want to initialize everything explicitly rather than relying on some speculative default value.