Rule Request: [container_types] Need new rule to require idiomatic container rules

[atlassian-gaustin]

New Issue Checklist

• [√] Updated SwiftLint to the latest version
• [√] I searched for existing GitHub issues

Rule Request

The "idiomatically-correct" types of containers are ContainerType<ElementType[, ElementType...]>. While the Swift documentation states that the syntactic sugar versions are preferred, there are points in the code where the sugar versions do not work because the idiomatically-correct type is required (Array<Int>.Index is valid, [Int].Index is an error).

The existing rule for syntactic_sugar rule disallows these or simply doesn't check (on/off). There needs to be a new rule (that deprecates syntactic_sugar) that allows checking for idiomatically-correct, syntactic sugar, or off.

• container_types **on** - type definitions of Array<Int> or Dictionary<String, Any> would pass, [Int] and [String: Any] would fail.
• container_types **sugar** - type definitions of [Int] or [String: Any] would pass, Array<Int> and Dictionary<String, Any> would fail.
• container_types **off** - type definitions of [Int], '[String: Any], Array, or Dictionary<String, Any>` would pass.

Default would be container_types sugar to match existing syntactic_sugar default of on. This would also require syntactic_sugar to be deprecated or mapped into this new rule as a synonym to 'sugar' or 'off'.

[marcelofabri]

I wouldn't deprecate syntactic_sugar though. This would be a new (opt-in) rule, just to check that the sugared versions are never used.

They are linked -- what would the result be if both were set to on?

You'd never be able to fix the warnings 😉
But I think that could be considered a configuration error. It's not worth to make the experience harder for everyone else just to support this style, which is not largely used by the community.

[atlassian-gaustin]

Make syntactic_sugar on a synonym for container_types sugar, and syntactic_sugar off a synonym for containers_types off. Same behavior.
Just because someone picked up on "preferred" in the documentation doesn't make it correct. The Swift docs say the syntactic sugar versions are "preferred" then go back to using the idiomatic versions in almost every case (at least in 3.1 and 4.0). That should be a clue...
To go back a few years, "the C++ community" used new [] and delete, even though new [] and delete [] were the correct pairing. I can still find code in shipping products that mixes the two. This is why "the community" isn't always correct.