[Rule] Prefer let-bindings over var-bindings wherever possible

[marcelofabri]

Check if a var ever changes. If not, let should be used.

key.setter_accessibility might be useful.

[segiddins]

Wouldn't you also need to check if any mutating methods /input functions are called with it?

[marcelofabri]

Yeah, this will be a trick one. We can't also predict anything on properties from public API (they might not change inside the file itself, but a consumer may change it).

[marcelofabri]

An easier way to do this is trying to replace every (non-public?) var with let and let the compiler check if it's still ok.

The problems are that this will probably be much slower and that neither syntax nor structure expose this error (but swiftc does).

[jpsim]

@mrackwitz is working on a parser for swiftc -dump-ast so hopefully that'll make it easier to build different kinds of SwiftLint rules based on that version of the AST.

[marcelofabri]

👍

I was just about to comment about swiftc -dump-ast and how helpful it would be.

[marcelofabri]

This is now a compiler warning on Swift 2.0, so maybe it should be closed.

[jpsim]

This is now a compiler warning on Swift 2.0, so maybe it should be closed.

Agreed. Plus, this would have been difficult to do without LLMV IR access.

[cprovatas]

Any chance of supporting this for class / struct properties? I noticed the swift compiler doesn't catch this. Is it too complex to support?

[jpsim]

It would be possible to build an analyzer rule to do that.