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.

[saschanaz]

rust-lang/rust#74127 and rust-lang/rust#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])

[hlopko]

Hi all, I'll try to fix this issue.