> I believe the reason why `@impl` is required is because if a callback is > optional, you can't warn about it missing, but the bug would be if someone > *thought* they were implementing the optional callback, but had the > signature wrong. >
Yes, exactly. > I do wonder though if it would be possible to check for function > definitions with the same name as a callback, but a signature which doesn't > match. > Unfortunately may led to false positives. > I'm +1 on all of these changes myself, though as a library maintainer, it > seems to me that there is a bit of a pain point with `defoverridable` > specifically, in that it takes a Keyword.t today, but will take atom() in > the new version. > The existing defoverridable API will continue to work as today. That won't change at all (nor be deprecated). -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JZyWaJsSkH7OKCzKWC2pMDCJTpTR2Ub-NsMVJO2zw1Ug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
