Rust-bindgen: Consider deprecating whitelist / blacklist APIs

[emilio]

(And replace them with some with more inclusive terms than those).

I'm not a native English speaker so help with naming would be appreciated... Blocklist / Allowlist? Something else?

[kulp]

Someone at Chromium / Google suggested "allow"/"block". "Allow" and "Block" have the (somewhat trivial) nice property that they are the same length as each other and as "White" and "Black" so it would not mess up alignment to do a global replacement, if we do this.

Does bindgen have an existing deprecation policy / process ?

[kulp]

I guess I did not really address how to form the whole words -- "allowlist" and "blocklist" seem fine, but I would like to hear others' opinions.

[jlucangelio]

We're using both allowlist (no space) and allow-list (dash) and blocklist (no space) and block-list (dash) in Chromium OS.

(Chiming in because these are the last uses of white/blacklist in https://github.com/google/minijail, which I was hoping to clean up: https://github.com/google/minijail/blob/master/rust/minijail-sys/lib.rs)

[wokecanary]

I understand replacing internal occurrences of "whitelist" with more descriptive terms, but this? Many many crates depend on bindgen. They'll all have to be "fixed".

Rust's community consists almost exclusively of smart people. How so many of them became convinced to spend time on this (and make others spend their time on it too) is beyond me. It's quite depressing, to be honest.

[tmfink]

@wokecanary I think we can avoid breakage by deprecating the current names and introducing new ones.

Whether we remove the deprecated names at a later release is a separate (independent) matter.

[emilio]

Right, the idea would be to mark the current APIs as deprecated and come up with better names for them. At some point in the future we can ideally remove the deprecated ones, but as @tmfink said that's a totally different matter.

[LoganDark]

(And replace them with some with more inclusive terms than those).

Personally I see no point to this reasoning. This whole "change every software term because diversity!" movement is purely political and I don't feel like Rust should have to be impacted by this. Other, more popular languages (and even platforms like GitHub) are taking the hit for us.

Whitelists and blacklists don't have anything to do with race/ethnicity/etc., so I don't see the point in removing every reference to "white"/"black" just because some people are sensitive to any use of those words (even if they're completely innocent).

[shadowcat-mst]

allowlist and blocklist are clearer terms, so adding those and encouraging people to use them will, overall, eventually make for better code at minimal cost.

also, frankly, the alternative is "keep having this argument every six months into the indefinite future" which will waste far more developer time than adding the new names and deprecating the old ones.

[TheButlah]

I never perceived the terms whitelist or blacklist to have anything to do with race. But that's just my perspective, and doesn't translate to others.

I see no reason that deprecating would do any harm to anyone - the deprecated terms don't even need to be removed, as the mere fact that they are deprecated will cause people to use the non-deprecated versions and the old terms will pop up less frequently, which is the intended goal.

~That being said, is there any evidence that these terms are offensive? I ask not to be contrarian, but I genuinely didn't perceive them that way and wouldn't expect someone else to. Does rust have any guidelines for what the threshold of objection is for a word to be considered non-inclusive? Is there any historical context to other uses of the terms that could shed light on why they might be offensive? For example, I'm assuming that there literal white lists and black lists during segregation - does the technical or colloquial term originate from those, or evoke parallels to them? It would be helpful to understand some of the motivation.~

EDIT: after looking at some of the linked posts, I see plenty of examples where this change was made in other projects, usually accompanied with a great deal of controversy. And in all the controversy, I don't see any reasons to oppose the change other than a general adverse reaction to what some perceive as "unnecessary inclusivity". Given that there is overwhelming precedent overruling that mentality, I see no reason that this change isn't a straightforward one.

If it helps make more people feel welcome, isn't that an important goal of any project or language? Thats not a political stance - its a practical one

[saschanaz]

https://github.com/rust-lang/rust/pull/74127 and https://github.com/rust-lang/rust/pull/74150 removed *list words altogether. Since there already is hide_type as an alias, it sounds like an option to me.

[LunarLambda]

I'd be heavily in favour of this too. For what it's worth, deprecating and renaming of functions has precedent in std. ([1], [2], [3])