SwiftUI generic view's preview problem

[el-hoshino]

New Issue Checklist

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

Describe the bug

2791 resolved the problem with normal SwiftUI preview type names like:

struct MyView: View {
    // ...
}

struct MyView_Preview: PreviewProvider {
    // ...
}

But if MyView has generics like the code below, a lint error will still be triggered

protocol: DataObject: ObservableObject {
    // ...
}

struct MyView<Object: DataObject>: View {
    // ...
}

struct MyView_Preview: PreviewProvider { // ← a lint error will be triggered here
    // ...
}

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

$ mint run swiftlint
🌱 Finding latest version of SwiftLint
🌱 Running swiftlint 0.39.2...
Loading configuration from '.swiftlint.yml'
Linting Swift files at paths 
Linting 'XXX.swift' (1/13)
Linting 'XXX.swift' (2/13)
Linting 'XXX.swift' (3/13)
Linting 'XXX.swift' (4/13)
Linting 'XXX.swift' (5/13)
Linting 'XXX.swift' (6/13)
Linting 'XXX.swift' (7/13)
Linting 'XXX.swift' (8/13)
Linting 'XXX.swift' (9/13)
Linting 'XXX.swift' (10/13)
Linting 'XXX.swift' (11/13)
Linting 'XXX.swift' (12/13)
Linting 'XXX.swift' (13/13)
Path/To/XXX.swift:148:13: warning: Closure Parameter Position Violation: Closure parameters should be on the same line as opening brace. (closure_parameter_position)
Path/To/XXX.swift:148:20: warning: Closure Parameter Position Violation: Closure parameters should be on the same line as opening brace. (closure_parameter_position)
Path/To/XXX.swift:90:82: error: Force Cast Violation: Force casts should be avoided. (force_cast)
Path/To/XXX.swift:196:29: warning: Colon Violation: Colons should be next to the identifier when specifying a type and next to the key in dictionary literals. (colon)
Path/To/XXX.swift:199:47: warning: Redundant Optional Initialization Violation: Initializing an optional variable with nil is redundant. (redundant_optional_initialization)
Path/To/XXX.swift:187:8: error: Type Name Violation: Type name should only contain alphanumeric characters: 'XXX_Preview' (type_name)
Done linting! Found 6 violations, 2 serious in 13 files.

(Replaced exact file names with XXX)

Environment

• SwiftLint version (run swiftlint version to be sure)? 0.39.2

• Installation method used (Homebrew, CocoaPods, building from source, etc)? mint

• Paste your configuration file:

included: # paths to ignore during linting. Takes precedence over `included`.
  - XXX
  - XXXTests
  - XXXUITests

disabled_rules:
  - trailing_comma
  - trailing_newline
  - trailing_whitespace
  - vertical_whitespace
  - duplicate_imports

identifier_name:
  max_length: 50
  excluded:
    - i
    - x
    - y
    - id
    - on
    - to
    - us
    - up
    - at
    - vc
    - ci

line_length:
  ignores_function_declarations: true
  ignores_comments: true
  warning: 175

type_name:
  max_length: 50

nesting:
  type_level:
    warning: 2
  statement_level:
    warning: 5

function_parameter_count:
  warning: 7
  error: 10

large_tuple:
  warning: 4

• Are you using nested configurations? If so, paste their relative paths and respective contents. No

• Which Xcode version are you using (check xcodebuild -version)? Xcode 11.6 Build version 11E708

• 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.

protocol: DataObject: ObservableObject {
    // ...
}

struct MyView<Object: DataObject>: View {
    // ...
}

// This triggers a violation:
struct MyView_Preview: PreviewProvider {
    // ...
}

[marcelofabri]

Looking at the code, I don't think this is related to the view being generic, but rather using _Preview instead of _Previews (in plural)

[el-hoshino]

@marcelofabri Oh, yes. my bad, I didn't notice it should be plural 😱 I'll close this issue since it's not a bug

[thisIsTheFoxe]

To be fair, it might not be a terrible idea to make _Preview acceptable as well..? .-.

[Skoti]

To be fair, it might not be a terrible idea to make _Preview acceptable as well..? .-.

Exactly, this also seems to be the default template in Xcode.