Shorthand Operator False Positive - String concatenation

[ghost]

The + operator is commutative when working with numbers, but when used for string concatenation it is not. For example, the following code is a violation with the rules currently:

var helloWorld = "world!"
helloWorld = "Hello, " + helloWorld

[jpsim]

heh

[marcelofabri]

I wonder if we should give up and just detect cases when the variable is the first operand 😅

[alistra]

[marcelofabri]

@alistra your example is actually a different problem and should be fixed on master

[jshier]

This still seems to be an issue with 0.22. This code triggers the warning in the += implementation:

extension NSAttributedString {
    static func + (lhs: NSAttributedString, rhs: NSAttributedString) -> NSAttributedString {
        let result = NSMutableAttributedString()
        result.append(lhs)
        result.append(rhs)
        return result
    }

    static func += (lhs: inout NSAttributedString, rhs: NSAttributedString) {
        lhs = lhs + rhs // Shorthand Operator Violation
    }
}

Unless I'm mistaken, there isn't a better way to express this.

[marcelofabri]

@jshier That's a different issue: you can't use the operator because you're actually defining it on that function. Please file another issue for that.

However, since that's not a super common case, I'd suggest you to use swiftlint:disable to ignore the violation for now.

[jshier]

@marcelofabri Before I file an issue, I'd like to understand it. I'm not sure what "actually defining it on that function" means. The + for NSAttributedString is defined above the += implementation. Also, like +, += should already be a defined operator from the standard library.

[marcelofabri]

You're defining += for NSAttributedString. As so, you can't use += in its implementation.

The rule always assume that you can use += when + is used. Currently, SwiftLint has no way to find every operator declared on a project/module: the only information we have when linting a file is from that file itself.

In your case, it'd be possible to avoid triggering a violation if we'd trigger it, but we're inside the definition of the shorthand operator that'd be preferred. Does that make sense?

[jshier]

Ah. I think you mean since + is defined by me, I can't use it in += without triggering the warning, as the warning can't tell that + is custom too. What issue would you like for this? Detection of custom operator pairs?

[marcelofabri]

It's not the + the problem. The problem is that you're inside the += definition. If you use += (which the rule wants you to do), you'd get an infinite recursion.

What we can do is check if a violation happens inside a shorthand operator definition (e.g. +=) and if the violation is triggered on the same operation (e.g. +).

[jshier]

Oh, so the warning always expects you to be able to use +=, even inside a custom += definition. So what issue would you like me to file here?

[marcelofabri]

Exactly that :)

The rule shouldn't want you to use a shorthand operator on its own function implementation.