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.

[emilio]

Thank you!

[ghost]

I do not mind this kind of change, as it isn't a breaking one, but IMO at least you replace those words with something clear, easy to understand, not awkward to read and already from the English dictionary.

filter could have been a good candidate. But well, the related PR is already merged.

[LunarLambda]

allow[list] / ban[list]

or, if you'd like both words to be the same length:
allow/block or accept/reject

my bad. missed the "related pr already merged" bit.

[kulp]

filter could have been a good candidate

I sympathize with the desire to use dictionary words, and in retrospect, blocklist sounds like a list of squares. But the old terms were unambiguously in my opinion likely to be parsed as nouns, whereas filter can be a noun or a verb. @JackRedstonia, can you explain how you would use filter to meet both sides of the need, both for allowing and blocking?

I think a common problem in cases like this one is that a superior solution seems easier than it is.

Regardless, I think we can probably consider this to have been closed by #1990. If someone thinks there is more work to be done, please elaborate.

[ghost]

I have just got time to look at code changes in #1990. As it is terminology used in public, exposed interfaces, IMO it is best to use ban/permit. The ideal solution is to not try to cram ...list into here. Try "Banning types for binding generation" for example.

If you want an example, please see that PR tamird opened on the Rust compiler. It is merged, it is perfect, no made-up words by a bunch of mad apologists.

[kulp]

@JackRedstonia, I agree that making up words is not good when clear alternatives exist, and I think the alternatives you and others pointed out are superior, maybe even in every way. When I previously said:

"allowlist" and "blocklist" seem fine

I had not given the implications of those specific word choices deep thought, and I expected alternative opinions to crop up soon thereafter. That is a reminder for me to avoid staking out a position, however weakly held, unless I can give it a positive rationale.

At any rate, I do not feel that this particular issue's resolution was rushed, just that this particular forum is little-trafficked enough to have avoided gleaning enough positive contributions "in time," so I guess we got a little unlucky that some of the later feedback was not just a bit earlier. If you see other lessons to be learned, feel free to share.

[dvc94ch]

well the reason for not jumping on the woke wagon is because in a few years when they fall on their noses we'll have to change everything back in order to avoid shame. why might you feel shame in a few years? because claiming that the words whitelist and blacklist are offensive to black people is indeed racist.

while I found allowlist to be quite fine, didn't even realize it was due to a woke agenda, the term blocklist confused me. block is an overloaded word. if anything I'd find denylist to better match the allowlist.

[peter9477]

Throwing in two cents more, I was confused by "blocklist", not because of the "squares" interpretation but because of the "groups of things" interpretation. So that's at least three possible connotations for "block". I would have preferred "banlist" or, better yet as there is precedent, "denylist". There have long been /etc/hosts.allow and /etc/hosts.deny files in Linux, and I think that precedent could have been followed instead. Too late now, I assume?

[pvdrz]

I'd favor allow/deny but that sail has shipped now