xpg
Deprecation warnings and warnings as errors
I generally enable warnings_as_errors in order to have the compiler fail hard in situations like invoking non-existing remote functions.
This worked well, until I started using @deprecated. As far as I see it, I now have to choose between the following two:
- Keep warnings as errors, and accept that
@deprecatedwill cause compilation errors. - Treat warnings as warnings, meaning that
@deprecatedwill only be a warning. But so will invocations of non-existing functions.
Is there a middle-ground I am missing? Where I can have warnings for deprecations, but errors for invoking non-existing remote functions.
Marked As Solved
LostKobrakai
The middleground is soft deprecation using @doc deprecated: "…", but I’m not sure you’ll see those when compiling.
Last Post!
xpg
That will do it, thanks.
It would be nice to be able to differentiate between warnings (unused variables vs. invoking non-existing remote functions, for instance). But I guess that will open a can of worms and/or a substantial set of compiler options (which wouldn’t really make anyones life easier) ![]()
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










