On Thursday, 8 November 2012 at 08:10:36 UTC, Don Clugston wrote:
On 07/11/12 14:16, monarch_dodra wrote:
There is some talk going on right now of changing "deprecate"
into a
UDA. There are some people saying that deprecate is broken, and
proposing some fixes (myself included). Instead of
concentrating on how
to "fix" it, and like to first study "what" is broken.
----
What exactly is supposed to be the lifetime of a deprecated
function?
What (default) behavior do we expect from deprecated?
**Timeline**
1. The function can be used normally.
Nothing to say here.
2. The function is *marked* for deprecation.
At this point, the user would like to be served with a
warning, that he
should consider migrating to a new function.
3. The function is fully deprecated. At this point, the user
shouldn't
be using it anymore, but if he really really wants to, he
should be able
to.
4. The function is blasted out of existenc.
----
The problem, IMO, comes from the fact that we actually have no
way to
implement "2". Because of this, there is a major gap in our
deprecation
process.
You are quite wrong. The problem is 3. There's actually nothing
wrong with "deprecated", the problem is the -d command line
option.
Suppose you want to continue using the function. There is no
reasonable way of doing it. If you use the -d option, you will
not be notified about 2. If something else is deprecated, you
won't find out about it.
Basically -- a warning should ALWAYS be printed for deprecated
functions, even if you are using -d. It's that simple.
There is a pull request to fix this situation. I don't know why
this discussion is happening.
So you are saying: keep the current behavior, but also print a
warning in -d mode?
