Typealias considered defining a Type with nesting

[matteobart]

New Issue Checklist

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

Describe the bug

Defining a typealias is considered to be creating type. This is problem when it is nested. I don't believe that this is to be the expected behavior especially since this can be unavoidable behavior when using Decodables with Protocols.

Complete output when running SwiftLint, including the stack trace and command used

$ swiftlint lint
/.../SpotifyItems.swift:129:16: warning: Nesting Violation: Types should be nested at most 1 level deep (nesting)

Environment

• SwiftLint version (run swiftlint version to be sure)? 0.39.2
• Installation method used (Homebrew, CocoaPods, building from source, etc)? Homebrew
• Paste your configuration file:

identifier_name:
    excluded: # excluded via string array
      - id
      - me

• Are you using nested configurations? Nope
  If so, paste their relative paths and respective contents.
• Which Xcode version are you using (check xcodebuild -version)? Xcode 11.4 Build version 11E146
• Do you have a sample that shows the issue? Run echo "[string here]" | swiftlint lint --no-cache --use-stdin --enable-all-rules to quickly test if your example is really demonstrating the issue. If your example is more complex, you can use swiftlint lint --path [file here] --no-cache --enable-all-rules.

public struct SpotifyPlaylist: Decodable {
    public struct Tracks: SpotifyPagingObject {
        public var items: [Item]?
        public typealias ItemType = Item // This triggers a violation
    }
    public struct Item: Decodable {
        public var track: SpotifyTrack
    }
}

struct AStruct {
    struct BStruct {
        typealias GreatType = C.Type
    }
    struct CStruct {

    }
}

<nopath>:2:5: warning: Convenience Type Violation: Types used for hosting only static members should be implemented as a caseless enum to avoid instantiation. (convenience_type)
<nopath>:1:1: warning: Convenience Type Violation: Types used for hosting only static members should be implemented as a caseless enum to avoid instantiation. (convenience_type)
<nopath>:3:9: warning: Explicit ACL Violation: All declarations should specify Access Control Level keywords explicitly. (explicit_acl)
<nopath>:2:5: warning: Explicit ACL Violation: All declarations should specify Access Control Level keywords explicitly. (explicit_acl)
<nopath>:5:5: warning: Explicit ACL Violation: All declarations should specify Access Control Level keywords explicitly. (explicit_acl)
<nopath>:1:1: warning: Explicit ACL Violation: All declarations should specify Access Control Level keywords explicitly. (explicit_acl)
<nopath>:1:1: warning: Explicit Top Level ACL Violation: Top-level declarations should specify Access Control Level keywords explicitly. (explicit_top_level_acl)
**<nopath>:3:9: warning: Nesting Violation: Types should be nested at most 1 level deep (nesting)**
<nopath>:6:1: warning: Vertical Whitespace before Closing Braces Violation: Don't include vertical whitespace (empty line) before closing braces. (vertical_whitespace_closing_braces)
<nopath>:6:1: warning: Vertical Whitespace after Opening Braces Violation: Don't include vertical whitespace (empty line) after opening braces. (vertical_whitespace_opening_braces)

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

[matteobart]

This is still an issue, just commenting to keep it from going stale

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

[matteobart]

Bump

[SimplyDanny]

One solution would be to add a configuration option to exclude type aliases and associated types from the analysis of the rule.

[marunomi]

@SimplyDanny plz check this out :)

This is my first time creating a pull request for OSS, so I would appreciate comments on any shortcomings.