It's often the case that a project values using `--warnings-as-errors`, yet the `deprecation` attribute conflicts with this option, in that it may be some time before a function gets hard deprecated. What's more, the function might be utilized across many modules such that it's not reasonable nor safe to update all modules all the same time.
After discussing this issue with Scott Southworth, we ended up with what seemed like a useful addition to `deprecated` attribute, an `:as` option that takes a log level argument. This conceivably would ease the adoption process of updated libraries that have soft deprecated functions or modules. This would allow a library author to set the deprecation to log level to `:notice` (as an example). When a "stronger" deprecation is deemed advantageous, library authors can change this to warning, and perhaps lib authors may even opt to switch to the error level before completely removing a function (though, how useful that would be is not clear). This has been discussed in the past I do believe, but iirc it was around filtering specific warnings from specific deps vs an extension to the `deprecated` attribute. Cheers. -- 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/4e214464-d005-44a1-87da-5fc394f3996fn%40googlegroups.com.
