Swiftlint: False positive `implicit_getter` violation when mentioning word "set" in a comment in custom getter of a read-write var

Created on 26 Mar 2020  Â·  17Comments  Â·  Source: realm/SwiftLint

New Issue Checklist

Describe the bug

Mentioning word "set" (without parentheses) in a comment in a get of a read-write var with both get and set defined triggers SwiftLint to think that this is a read-only property.

image

Complete output when running SwiftLint, including the stack trace and command used
$ swiftlint lint --path Test.swift --no-cache --enable-all-rules
Loading configuration from '.swiftlint.yml'
Linting Swift files at paths Test.swift
Linting 'Test.swift' (1/1)
/Users/yas/code/caremobile/Test.swift:3:9: warning: Implicit Getter Violation: Computed read-only properties should avoid using the get keyword. (implicit_getter)
Done linting! Found 1 violation, 0 serious in 1 file.

Environment

  • SwiftLint 0.39.1
  • Installation method used: Homebrew
  • Paste your configuration file:
excluded:
  - Pods

opt_in_rules:
  - array_init
  - contains_over_first_not_nil
  - collection_alignment
  - contains_over_filter_count
  - empty_count
  - empty_collection_literal
  - overridden_super_call
  - sorted_first_last
  - yoda_condition

disabled_rules:
  - cyclomatic_complexity
  - file_length
  - force_cast
  - force_try
  - function_body_length
  - function_parameter_count
  - identifier_name
  - large_tuple
  - line_length
  - multiple_closures_with_trailing_closure
  - nesting # consider
  - notification_center_detachment
  - operator_whitespace
  - todo # fix
  - type_body_length
  - type_name # consider
  - weak_delegate # fix

statement_position:
  statement_mode: uncuddled_else
  • Are you using nested configurations?No

  • Which Xcode version are you using (check xcodebuild -version)?
    Xcode 11.4
    Build version 11E146

  • Do you have a sample that shows the issue?
    Yes:

Test.swift

extension Test {
    var foo: Bool {
        get {
            bar?.boolValue ?? true // Comment mentioning word set which triggers violation
        }
        set {
            bar = NSNumber(value: newValue as Bool)
        }
    }
}

If I don't mention word "set" in the comment then it seem to work fine.
I don't recall seeing this issues prior to updating to Xcode 11.4.

Hope it helps.

bug

Most helpful comment

I found another false-positive. When the set is before the get you get warning. If it is the other way round then everything is all right. I believe another rule could be created to formalize the order of get-set.

extension Float {
    var clamped: Float {
        set {
            self = min(1, max(0, newValue))
        }
        get {
            min(1, max(0, self))
        }
    }
}

Command:

swiftlint

Output:

Linting Swift files at paths 
Linting 'lint.swift' (1/1)
/Users/kaspar/Downloads/swiftlint-issue/lint.swift:6:9: warning: Implicit Getter Violation: Computed read-only properties should avoid using the get keyword. (implicit_getter)
Done linting! Found 1 violation, 0 serious in 1 file.

All 17 comments

Oh, thanks. I somehow missed that PR during my search for existing reports.
Based on the description I guess it is indeed supposed to fix this issue... But I'm running current SwiftLint version (0.39.1), which includes that fix, and I'm still getting the issue. So perhaps there is something else needs to be done. Maybe something around swift version check? Not sure...

It doesn’t include that fix IMO

0.39.1 is almost two months old,
I imagine they’ll accumulate some content and release 0.40 soon

From what I see, 0.39.1 already includes that code (https://github.com/realm/SwiftLint/commit/4e84992a4a5035776ef42c1ca4f2c299a9f0a744):
https://github.com/realm/SwiftLint/blob/0.39.1/Source/SwiftLintFramework/Rules/Style/ImplicitGetterRule.swift#L29-L51

It's also triggering a false positive if we have both a get and a nonmutating set:

extension Reactive where Base: UITapGestureRecognizer {

    var tapped: CocoaAction<Base>? {
        get {
            return associatedAction.withValue { $0.flatMap { $0.action } }
        }

        nonmutating set {
            setAction(newValue)
        }
    }
}

I found another false-positive. When the set is before the get you get warning. If it is the other way round then everything is all right. I believe another rule could be created to formalize the order of get-set.

extension Float {
    var clamped: Float {
        set {
            self = min(1, max(0, newValue))
        }
        get {
            min(1, max(0, self))
        }
    }
}

Command:

swiftlint

Output:

Linting Swift files at paths 
Linting 'lint.swift' (1/1)
/Users/kaspar/Downloads/swiftlint-issue/lint.swift:6:9: warning: Implicit Getter Violation: Computed read-only properties should avoid using the get keyword. (implicit_getter)
Done linting! Found 1 violation, 0 serious in 1 file.

@marcelofabri thanks a lot!

thanks for everyone reporting different minimal examples! this has been very helpful to fix the issue quickly

Not sure if this fits in the same fix:

image

Which release is this going to and when?

The fix will go in the next release, either 0.39.2 or 0.40.0, depending on how we choose to version it. That’ll be in the next few days probably. Depends on if we think we can get more Swift 5.2 fixes in time.

@freak4pc can you see if the latest commit from master fixes that for you?

Looking forward to the fixing release. My code below still triggers this false positive on 0.39.1:

import Foundation

extension UserDefaults {
    var didShowWelcomeWindow: Bool {
        set {
            self.set(newValue, forKey: "didShowWelcomeWindow")
        }
        get {
            return bool(forKey: "didShowWelcomeWindow")
        }
    }
}

Update: it resolves if I move the getter _above_ the setter:

```
var didShowWelcomeWindow: Bool {
get {
return bool(forKey: "didShowWelcomeWindow”)
}
set {
self.set(newValue, forKey: "didShowWelcomeWindow”)
}
}

no fix ?

@jpsim my issues are fixed on the last master

u need find file : .swiftlint.yml , then just do it

disabled_rules: 
  - implicit_getter

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Igor-Palaguta picture Igor-Palaguta  Â·  23Comments

Oliver-Kirkland-Evoke picture Oliver-Kirkland-Evoke  Â·  31Comments

ghost picture ghost  Â·  31Comments

mohamede1945 picture mohamede1945  Â·  16Comments

marcelofabri picture marcelofabri  Â·  19Comments