Re: [elixir-core:11599] Re: [Proposal] `as: level` for deprecrated attribute

[Wojtek Mach]

This is fairly specialized scenario so I’d go with a specialized solution. How about this: do your build in a build.sh, compile without warnings as errors however in the script inspect stderr and fail on a "warning: " unless that warning is for a deprecation. Hopefully fairly straightforward regexps would suffice (now you have N+1 problems nonwithstanding). Less complexity in the toolchain, less churn for maintainers (as they’d have to use the suggested :as annotation), and more control to you, make the script as simple or as complicated as you need it to be. Wiadomość napisana przez Kip <kipco...@gmail.com> w dniu 21.11.2023, o godz. 00:45: A few thoughts, only to aid the conversation: 1. As a library writer I do feel the need to ensure compiler warnings are eradicated during the RC cycle of the next Elixir release.  While this definitely puts pressure on me (Im maintaining around 40 libs at the moment), it does act as a strong motivator to keep up-to-date and minimise DX issues for consumers.  I'm not sure I would trust myself to just lower the log level and never come back. 2. We do already have the hard deprecation `@deprecated` and soft deprecation `@doc deprecated: "Some deprecation notice"`. Do you not think that caters for much of what you propose? See https://hexdocs.pm/elixir/1.15.4/writing-documentation.html#documentation-metadata Yes, I appreciate they both still emit warning messages, but only one of them halts compilation with `--warnings-as-errors`. On Tuesday, November 21, 2023 at 5:00:42 AM UTC+7 erlef.bry...@gmail.com wrote:  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/0579affe-a9b2-4e50-bd81-b47962b7356dn%40googlegroups.com. -- 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/FC0D4FCD-7413-4C63-B193-36DE1DC6B4B1%40wojtekmach.pl.