False positive for `unused_enumerated`

[carl8382]

New Issue Checklist

• I've Updated SwiftLint to the latest version.
• I've searched for existing GitHub issues.

Bug Description

There's a false positive for the rule unused_enumerated. The offset given from enumerated is used, just apparently not fast enough.

// This triggers a unused_enumerated  violation:
let previousValueComponent = "1234"
let currentValueComponent = "1434"

                // Compare previous and current components and find if there are any indexes where:
                // - two characters are digits
                // - these two digits are different
                //
                let firstIndexWithDifferentDigit = zip(previousValueComponent, currentValueComponent)
                    .enumerated()
                    .first {
                        $0.element.0.isNumber &&
                        $0.element.1.isNumber &&
                        $0.element.0 != $0.element.1
                    }?.offset

                return firstIndexWithDifferentDigit

Mention the command or other SwiftLint integration method that caused the issue. Include stack traces or command output.

$ swiftlint lint [--no-cache] [--fix]

Environment

• SwiftLint version (run swiftlint version to be sure) 0.57.1
• Xcode version (run xcodebuild -version to be sure) 16.0
• Installation method used (Homebrew, CocoaPods, building from source, etc) SPM
• Configuration file:

# insert yaml contents here

Are you using nested configurations? If so, paste their
relative paths and respective contents.

[ortekka]

For reference, here's an even simpler code snippet that triggers a false positive:

public extension Array where Element: Comparable {
	var maxIndex: Int? {
		self.enumerated().max { $0.element < $1.element }?.offset
	}
}

Just because offset isn't used in the closure doesn't mean that .enumerated() can be removed, as the warning message incorrectly suggests.

[rgoldberg]

Is this scheduled to be fixed? Thanks.

[SimplyDanny]

Is this scheduled to be fixed? Thanks.

Well, we don't schedule topics. Whoever wants to, may work on it.

[theamodhshetty]

Opened #6544 for this. The fix carries result-member usage from the surrounding higher-order call back into the check, so cases like stop getting flagged while the existing real violations still trigger.

[theamodhshetty]

Opened #6544 for this. The fix carries result-member usage from the surrounding higher-order call back into the rule, so cases like .max { ... }?.offset stop getting flagged while the existing real violations still trigger.