You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the goals of this feature is to keep the maintainance cost low, and to not let this feature hinder the pace of the overall development of the compiler. Because of that, the tests can be freely disabled in compiler/neg-best-effort.blacklist (testing TreePickler) and compiler/neg-best-effort-from-tasty.blacklist (testing TreeUnpickler).
While the etymology of these words has no relation to racism, their use suggests an association between the color black and some form of badness or exclusion, and between the color white and some form of goodness or inclusion. Prefer alternatives when possible. Several alternatives have been proposed but none sticks as “the one”. We suggest using the pair denylist/allowlist or the pair excludelist/includelist, as these are generic enough to replace most uses of blacklist/whitelist.
Expectation
Thankfully, the term seems to be mostly limited to GitHub issues and testing, so I'd appreciate it if we could switch to something like excludelist. Thanks!
The text was updated successfully, but these errors were encountered:
While we're at it, we can take the opportunity to audit the whole codebase, focusing on usage of inclusive language.
Optionally, we could even have a script to check for words we should avoid automatically.
While adding the aforementioned exclusion lists I considered changing the name, but all of the other exclusion lists in compiler/test/dotc already had that standardized naming scheme - I feared breaking out of that would unjustly paint those past additions a certain way, which I wanted to avoid. I didn't think about having to mention these in user-facing documentation, which ended up happening here (I apologize!). Having all of those files in compiler/test/dotc changed all together at once seems like a great solution I fully support!
I feared breaking out of that would unjustly paint those past additions a certain way, which I wanted to avoid.
As an aside, I think we should be unafraid to correct courses especially if it makes our own or peer's past decisions less informed. Otherwise, we're now making an informed mistake. See also "Pimp my library" terminology being used, long after it was considered passé among some circle.
Steps
See https://dotty.epfl.ch/docs/internals/best-effort-compilation.html
Problem
This is a friendly reminder about Inclusive Language Guide - https://docs.scala-lang.org/contribute/inclusive-language-guide.html
Expectation
Thankfully, the term seems to be mostly limited to GitHub issues and testing, so I'd appreciate it if we could switch to something like
excludelist
. Thanks!The text was updated successfully, but these errors were encountered: