Swiftlint: Operator whitespace.

Created on 7 Sep 2017  ·  4Comments  ·  Source: realm/SwiftLint

Bug Report

Operator Function Whitespace Violation: Operators should be surrounded by a single whitespace when defining them. (operator_whitespace)

// This triggers a violation:
public static func <(lhs: CGPoint, rhs: CGPoint) -> Bool {
question

Most helpful comment

This is not a bug; it is precisely what the rule was designed to do. The rule expects the following:

public static func < (lhs: CGPoint, rhs: CGPoint) -> Bool {}

The clarity of this style becomes more apparent when the function signature is more complicated:

func <<<T : BitShiftable>(lhs: T, rhs: T) -> T {}
//   ?!?

vs

func << <T : BitShiftable>(lhs: T, rhs: T) -> T {}
//     ↑

You can always disable the rule if you prefer the unspaced style. In that case, you are not be alone. One reason would be that it is more consistent with non‐operator function declarations, which definitely look odd when they are spaced.

All 4 comments

This is not a bug; it is precisely what the rule was designed to do. The rule expects the following:

public static func < (lhs: CGPoint, rhs: CGPoint) -> Bool {}

The clarity of this style becomes more apparent when the function signature is more complicated:

func <<<T : BitShiftable>(lhs: T, rhs: T) -> T {}
//   ?!?

vs

func << <T : BitShiftable>(lhs: T, rhs: T) -> T {}
//     ↑

You can always disable the rule if you prefer the unspaced style. In that case, you are not be alone. One reason would be that it is more consistent with non‐operator function declarations, which definitely look odd when they are spaced.

@SDGGiesbrecht but this not correct. We can interpret < as the name of function. Apple not paste space after too.

Feel free to disable the rule if you want.

i'm closing this because it's not a bug, it's what the rule was meant to do. That rule was based on the GitHub Swift Style Guide, which is the main inspiration for SwiftLint rules.

Was this page helpful?
0 / 5 - 0 ratings