Improving deprecation management

[Jacob Carlborg]

On 2013-11-13 18:19, Dicebot wrote:
> There is one thing that seems really inconvenient to me but I'd like to
> see community opinion before writing a DIP :) It is all about current
> semantics of "deprecated" attribute.
>
> Right now using deprecated symbols is a warning. And if you use "-w"
> switch (like most pedantic projects do) it is an error that halts the
> compilation. It is possible to use "-d" to avoid breaking stuff but then
> it will just work silently, with no message at all.
>
> In practice, I tend to always apply the following deprecation path:
>
> 1) Modify the code to print message about upcoming deprecation (via
> pragma(msg))
> 2) On previously defined date mark symbol as deprecated and define
> expected removal date
> 3) Remove it completely
>
> It is very inconvenient to do manually but necessary to make deprecation
> process smooth - initially I just want to make users aware that some
> time should be scheduled to adjust their code in future, without any
> interfering with normal compilation. Then do actual deprecation that
> will result in an error but still provide meaningful message about
> changes that need to be made. And only after that removal is viable.
>
> I'd really love to be able to provide date/time parameter in some way to
> deprecate attribute and let compiler do all this routine for me
> automatically - just print message (not a warning) if compiled before
> the date, act as it does now after.
>
> So far I have not found see any way to define a good deprecation path
> with an existing toolset.
>
> Opinions / recommendations?

AST macros :)

-- 
/Jacob Carlborg