EEP-74 describes a solution for doing this. If/When implemented, it would be used by all languages running on top of Erlang. Though each compiler would have to implement support for emitting/silencing the warnings.

PR-10032 is a first step in adding this to the Erlang compiler though, as you can see in the comments, it is currently stalled.

Huh? The strongly-identified warning is not an ID associated with it, but rather ID+location/code snippet pair. I like the idea of identifying the warnings by ID, but for God’s sake let’s do it properly. The ID as per Rust/TS is nothing but a cludge. There is not much sense in having a short alias for a warning, specifically in the era of machines reading the code. The ID+snippet allows addressing, sharing, and even debugging without a context.

Joe Armstrong has proposed the very same thing for the whole internet once.

Strongly-identified warnings are common in Typescript and Rust, but only at the language compiler level. This is possible to implement via discipline and convention alone. I like them a lot, and Elixir could do similar, but that only gets us part of the way there. You’re asking for library-level warning ids, which requires tooling in the stdlib for registering ids across dependencies, emitting strongly-identified warnings separately from/alongside normal logger configuration mechanisms, then suppressing them. It’d be a big lift!

Worth noting that you can silence warnings today at the dependency, module, and function level already via compile_time_purge_matching. This ability is strictly more flexible than what you propose, but lacks the ability to semantically recognize a warning across changes in dependency versions. I’d argue it’s still better, because a semantically similar warning (with the same “id”) might be omitted from a new codepath in a library in a future version, and you wouldn’t want your existing code to suppress it.