Swiftlint: inclusive_language erroneusly warning on the term 'blacklist'

[owenworley]

New Issue Checklist

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

Describe the bug

The etymology of the word 'blacklist' is not exclusive nor has any racial connotations.

The first known use of the term appears to be in The true peace-maker: laid forth in a sermon before his Majesty at Theobalds written by the Bishop of Norwich, Joseph Hall, in 1624:

_"Ye secret oppressors,..ye kind drunkards, and who euer come within this blacke list of wickednesse."_

The word black when used in this context refers to negative connotations, and is attested as such way before 1624. The term blackball, which is first attested in 1550, describes the act of placing a black ball into a container as a means of recording a negative vote (and vice-versa using a white ball to record a positive vote).

Use of the term blacklist first gained credence and popularity from British blockade efforts during World War I. Over the course of 1915 and 1916 British government agencies gradually developed an implemented a system whereby neutral firms and individuals suspected of trading with or otherwise aiding the Central Powers would be denied access to Entente infrastructure such as ship bunker, financial services and communications.

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

$ swiftlint lint

1363 Error: Inclusive Language Violation: Declaration of modelTypeBlacklisted contains the term "blacklist" which is not considered inclusive (inclusive_language)

Environment

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

# insert yaml contents here
default

// This triggers a violation:
let modelTypeBlacklisted =  true

[jpsim]

Thanks for engaging in discussion around this new rule.

Firstly, there appears to be some controversy around whether or not "whitelist" and "blacklist" are racially charged words, so this isn't as clear cut as your description appears to make it out to be.

Overall, I'm in favor of keeping "blacklist" and "whitelist" as trigger words to report inclusive_langauge rule violations for likely the same reasons that have led many other software projects to rename or remove references to these terms.

On a personal note, I've found that these terms aren't as descriptive as some alternatives in many cases. Take for example our renaming of SwiftLint's configuration key "whitelist_rules" to "only_rules". The latter makes it crystal clear unlike the former that only the specified rules will be applied.

Finally, this rule is trivially configurable, where you can specify either words to append to the trigger words (additional_terms), or replace it altogether (override_terms). See the inclusive_language documentation page for full details. I'm sure there are plenty of good reasons to refer to these words, either for legacy, compatibility or other reasons, so we made sure to make the rule very flexible. It can also be disabled if need be.

@daltonclaybrook for visibility

[owenworley]

I'm sure there are plenty of good reasons to refer to these words, either for legacy, compatibility

Firstly, there appears to be some controversy around whether or not "whitelist" and "blacklist" are racially charged words

I agree with your points here, however enabling this rule as default has caused numerous projects that I manage start failing in CI, hence me whining here <3. Also, given the differing opinions on the etymology of the words in question, enforcing this rule as default seems premature and divisive. Does it not set a precedent for future opinionated rules that could be added which would be enabled by default as this has been?

[owenworley]

This PR in the swiftlint repo demonstrates the issue of enabling this rule as default:
https://github.com/realm/SwiftLint/pull/3422

Many linting failures, and this is a tiny snapshot of the number of repos that use swiftlint

[jpsim]

Thanks for sharing your thoughts @owenworley. It's not uncommon for us to introduce new rules that have many more violations than the < 20 that OSSCheck found for this rule when we introduced it. SwiftLint has always been an opinionated linter, and the goal when introducing new rules that are on by default isn't to avoid reporting violations in existing projects, but rather to assess if the violations being surfaced demonstrate any edge cases that we failed to consider.

And all but one are good candidates for finding a better term, from the point of view of clarity and descriptiveness and avoiding what some consider to be racially charged terminology. The exception is a bug that's flagging "mastercard" as a violation, and that bug is actively being fixed in https://github.com/realm/SwiftLint/pull/3422.

[jpsim]

I just found an IETF proposal from this summer that specifically highlights the terms we've enabled by default in the inclusive_language rule as particularly insidious in software.

The proposal suggests a number of alternative terms which is a good resource if you're having trouble naming things in your projects in a way that avoids offensive terminology.

[adozenlines]

For crying out loud, these two terms have major significance in software design and control systems why is this even being made into a race issue when there is none.

[daltonclaybrook]

@adozenlines This rule can be trivially disabled if you prefer to continue using these terms in your project, but aside from the specific issue of using inclusive language, the proposal linked above makes the following point:

Indeed, our technical argument is incredibly succinct: Why use a metaphor when a direct description is both succinct and clear? There can be absolutely no ambiguity if one uses the terms, as suggested below, allow-block rather than white-black.

Whether or not you agree that these terms are offensive to some people, it's hard to argue that they are a better choice than allow/block, which are objectively less ambiguous terms.

[isaac-weisberg]

Went political, I see, the SwiftLint management has...