Rule request: Discourage 'NSRange(location:length:)' based on String indices/counts

New Issue Checklist

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

New rule request

1. Why should this rule be added? Share links to existing discussion about what
   the community thinks about this.

I recently learned that NSRange(location:length:) does not work well with Swift's String type.

For instance, this code to get a range that spans the entire string:

NSRange(location:0, length:myStringVar.count)

…will fail you because myStringVar.count correctly accounts for emoji & co. (i.e., returns a count that reflects the amount of characters as perceived by a human reader), but NSRange(…) loses that contextual information as it only stores an integer length. An API that consumes the NSRange, e.g., NSRegularExpression's firstMatch(in:options:range:) will not know how this integer came to be and will not consider emoji when traversing the same string, leading to index mismatches. The same applies for the location parameter if it's not 0.

Swift’s Range is not Integer-based but uses a generic index, e.g., String.Index. So myStringVar.startIndex..<myStringVar.endIndex is a valid range that spans the entire string, incl. emoji.

Because some APIs require NSRange instead of Range, you can use this helper that lets you convert between the two without messing up string indices:

NSRange(myStringVar.startIndex..<myStringVar.endIndex, in: myStringVar)

It would be great if the linter could encourage this, or the other way around: discourage creating NSRange values from string character counts.

2. Provide several examples of what would and wouldn't trigger violations.

Triggering examples:

NSRange(location:0, length:myStringVar.count)
NSRange(location:4, length:"hello-world".count)
NSRange(location:myStringVar[3], length: 10)
NSMakeRange(0, myStringVar.count)
NSMakeRange(myStringVar[3], 10)

Non-triggering examples:

NSRange(location:0, length: 5)
NSMakeRange(0, 5)
NSRange(myStringVar.startIndex..<myStringVar.endIndex, in: myStringVar)

3. Should the rule be configurable, if so what parameters should be configurable?

I have not looked into the complexity of implementing such a rule. It may be challenging to find out whether the length/location is derived from a string count/integer index. One option could be to discourage these APIs entirely, which would also catch cases where the index/length was stored in a variable before. It would, of course, also create false positives.

4. Should the rule be opt-in or enabled by default? Why?

Opt-in, especially if we have known false positives.

No repository files, tests, or entry points are identified in the issue. Start by reviewing the requested NSRange and NSMakeRange examples and the proposed opt-in behavior; done means agreeing on scope and configuration, then adding coverage for the triggering and non-triggering cases.