Analyzer Rule Request: `prohibited_property_type` (maybe just `prohibited_substring_property`)

New Issue Checklist

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

New Rule Request

Please add a prohibited_property_type analyzer rule (maybe just prohibited_substring_property).

It should also apply to global values, so maybe property is a misnomer (prohibited_longterm_storage_type is a little unwieldy…).

Substring shouldn't be stored longterm (e.g., as property values), because they keep the rest of the original String in memory.

Maybe other types shouldn't be stored longterm (pointers?).

This must be an analyzer rule because it must know what various functions, bindings, etc. return for inferred binding types.

A normal rule could be made for explicit binding type annotations, but I doubt people would intentionally longterm store Substrings or other inadvisable types.

If prohibited_property_type, then could be configured via a types (or prohibited_types) option: a list of prohibited type names, defaulted to some array of strings that includes Swift.Substring, maybe Swift.StringProtocol, various pointer types, etc.

To avoid naming clashes, should support Swift 6.3+ module selectors (e.g., Swift::Substring), but also pre-6.3 name spacing (e.g., Swift.Substring). The default type names should use module selectors for Swift 6.3+, otherwise old name spacing.

I don't know if it's possible, but it would be nice to optionally append to the defaults or replace them. That should probably be standardized across all multi-value SwiftLint options (array, dictionary, anything else), so is a broader discussion if not already implemented.

It would also be useful to support module selectors in all other type name options, have their defaults use module selectors for Swift 6.3+, and provide a linter for .swiftlint.yml that suggests using module selectors if targeting Swift 6.3+ (I don't know if SwiftLint picks that up from any existing files or has its own target Swift version setting). Obviously, this would be yet another feature, but I figured I'd mention this & other general improvements here to gauge interest.

There could be another array option of types of storage to which to apply this rule, like instance properties, static properties, global values, etc. I guess there could also be a three-value option to apply this tule to var, let, or both. These 2 option, however, might be overkill. If the options are implemented, I think their defaults should be maximal (i.e. all types of storage & both var & let).

I think all analyzer rules are opt-in, so this would also be opt-in.

Start by reviewing SwiftLint's existing analyzer rules and configuration options, since the issue does not identify specific files or tests. Establish the supported storage scopes, prohibited type-name configuration, Swift module-selector handling, and default behavior before implementation; done means the opt-in rule reliably detects configured long-term storage of prohibited types and has coverage for its configuration.