Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RedundantTypeAnnotation: add 'ignore_type_interfaces' option #5839

Merged
merged 3 commits into from
Nov 12, 2024

Conversation

jaredgrubb
Copy link
Contributor

The redundant_type_annotation and explicit_type_interface rules conflict. For users that want to have an explicit type interface, but still be able to write simple code inside the bodies of functions, I want to add an option to redundant_type_annotation that has it ignore "type interfaces".

For example, this allows:

struct Foo {
    var bar: Bar = Bar() // OK: ignore this! I want explicit types on interfaces.
    func baz() {
       let bar: Bar = Bar() // WARN: redundant_type_annotation kicks in here though.
    }
}

I suggest that this addresses the complaint made in Issue #3750.

@SwiftLintBot
Copy link

SwiftLintBot commented Oct 28, 2024

17 Messages
📖 Linting Aerial with this PR took 0.92s vs 0.92s on main (0% slower)
📖 Linting Alamofire with this PR took 1.27s vs 1.26s on main (0% slower)
📖 Linting Brave with this PR took 7.19s vs 7.2s on main (0% faster)
📖 Linting DuckDuckGo with this PR took 5.11s vs 5.09s on main (0% slower)
📖 Linting Firefox with this PR took 10.67s vs 10.63s on main (0% slower)
📖 Linting Kickstarter with this PR took 9.89s vs 9.9s on main (0% faster)
📖 Linting Moya with this PR took 0.53s vs 0.53s on main (0% slower)
📖 Linting NetNewsWire with this PR took 2.86s vs 2.86s on main (0% slower)
📖 Linting Nimble with this PR took 0.77s vs 0.78s on main (1% faster)
📖 Linting PocketCasts with this PR took 8.61s vs 8.61s on main (0% slower)
📖 Linting Quick with this PR took 0.45s vs 0.44s on main (2% slower)
📖 Linting Realm with this PR took 4.52s vs 4.5s on main (0% slower)
📖 Linting Sourcery with this PR took 2.31s vs 2.31s on main (0% slower)
📖 Linting Swift with this PR took 4.5s vs 4.51s on main (0% faster)
📖 Linting VLC with this PR took 1.25s vs 1.25s on main (0% slower)
📖 Linting Wire with this PR took 17.68s vs 17.72s on main (0% faster)
📖 Linting WordPress with this PR took 11.35s vs 11.35s on main (0% slower)

Generated by 🚫 Danger

Copy link
Collaborator

@SimplyDanny SimplyDanny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new option makes sense to me. Thanks for adding it!

Copy link
Collaborator

@SimplyDanny SimplyDanny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @jaredgrubb!

Jared Grubb added 2 commits November 12, 2024 19:34
The `redundant_type_annotation` and `explicit_type_interface` rules conflict.
For users that want to have an explicit type interface, but still be able to write
simple code inside the bodies of functions, I want to add an option to
`redundant_type_annotation` that has it ignore "type interfaces".

For example, this allows:
```
struct Foo {
    var bar: Bar = Bar() // OK: ignore this! I want explicit types on interfaces.
    func baz() {
       let bar: Bar = Bar() // WARN: redundant_type_annotation kicks in here though.
    }
}
```
@SimplyDanny SimplyDanny force-pushed the jgrubb-redundant-type-interfaces branch from a041b3a to a81abc5 Compare November 12, 2024 18:36
@SimplyDanny SimplyDanny enabled auto-merge (squash) November 12, 2024 18:37
@SimplyDanny SimplyDanny disabled auto-merge November 12, 2024 18:38
@SimplyDanny SimplyDanny enabled auto-merge (squash) November 12, 2024 18:39
@SimplyDanny SimplyDanny force-pushed the jgrubb-redundant-type-interfaces branch from 812e928 to ba345ca Compare November 12, 2024 19:00
@SimplyDanny SimplyDanny merged commit fb3ce5a into realm:main Nov 12, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants