I too would find a lot of value in this or. Here is the thread that brought me here, https://elixirforum.com/t/how-can-i-suppress-warnings-ive-been-looking-for-a-while/60912
It seems y'all are pretty adamant about not supporting this, but what do you think would be the level of effort to have some rough take on it? If it's a rather small change I would consider building my own fork just to use personally. my three ideas. 1) per warning type suppression 2) warning suppression entirely 3) separate warning and error output via (stdout for warning, and stderr for error) On Tuesday, September 27, 2022 at 4:11:52 AM UTC-4 José Valim wrote: > At the moment we have don't have plans to introduce options to skip > warnings, except if the warnings may have false positives. > > For deprecation, typically doing it in two steps is the recommended > option, especially for libraries: a couple releases with "@doc deprecated" > and then the official deprecation. :) > > > On Tue, Sep 27, 2022 at 9:25 AM Maciej Małecki <smt...@gmail.com> wrote: > >> Erlang supports disabling a given warning using compilation configuration >> (see https://www.erlang.org/doc/man/compile.html). There are use cases >> for letting developers decide what they treat as a warning and what not. >> For instance, I'm using `--warnings-as-errors` when compiling the code for >> production. However, it is impossible to use `deprecated` tags anymore as >> the complication will fail. I treat deprecations special here because some >> refactorings can't be done in a single run or some of them don't make sense >> as the code is legacy anyway. >> >> I know that there is a `doc deprecated: "..."` mechanism, but it just >> feels right to use `deprecated` and still allow the `--warnings-as-errors`. >> The difference between those two would be: no warning during the >> compilation, but still logging the message when invoking the function. >> >> This could be implemented similarly to `no_warn_undefined` (see >> https://hexdocs.pm/elixir/1.14.0/Code.html#put_compiler_option/2). >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-co...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/0b7281bd-62ae-4a65-a153-eabfe90d5551n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/0b7281bd-62ae-4a65-a153-eabfe90d5551n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/b5cd5053-2b78-4143-8a2c-c9814fee981an%40googlegroups.com.
