unneeded_override breaks fixes for "Automatic Initializer Inheritance" about swiftlint HOT 7 CLOSED

The problem is that the rule implementation for autocorrect is not respecting the new affect_initializers configuration (which defaults to false). This means that linting behavior didn't change with the new release, but autocorrection did.

from swiftlint.

The problem is that the rule implementation for autocorrect is not respecting the new affect_initializers configuration (which defaults to false). This means that linting behavior didn't change with the new release, but autocorrection did.

Aha ... then this should be an easy fix.

from swiftlint.

Hm ... so is this rule useful for initializers at all? Feels like valid findings would be rare.

from swiftlint.

I think it has its uses for initializers, but the chance of breaking the build is too high.
If it was an opt-in-only rule it would be more clear which rule caused the issue.
Also, not-autofixing the initializers and instead showing a warning only would allow it to easily disable the rule for this very initializer if the situation outlined in the stack overflow issue occurs.

from swiftlint.

Disabling the rule for a specific initializer should work anyway. Doesn't it?

As the rule has been available for the last two releases already, changing it to opt-in would be breaking and could lead to surprises. Not sure yet if we should do that.

from swiftlint.

from swiftlint.

The problem is that the rule implementation for autocorrect is not respecting the new affect_initializers configuration (which defaults to false). This means that linting behavior didn't change with the new release, but autocorrection did.

that explains what we experienced

from swiftlint.