On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis
wrote:
Agreed. Otherwise, you can't deprecate something without
immediately breaking
code, which means that if you're trying to never immediately
break people's
code when making a change (which is the position that Phobos is
in), then you
can't use deprecated.
[SNIP]
- Jonathan M Davis
The problem with this approach is that the step after marking
something deprecated is removing the function. So people using
something deprecated go from
- "warning: Don't use this" (yeah... whatever...)
- "Your function has disappeared". (Oh oh)
At this point, they're fucked bad because they can't even bypass
the problem with an extra -d command line option, which (in my
eyes) is "pretty please, I'll change it, just give me a bit more
time".
IMO, there *NEEDS* to be some way of saying
- "this _will_ be deprecated soon (marked for deprecation), you
should consider migrating to something else. here is you warning."
and
- "This is already deprecated. Here is your error. You can
*still* use it with -d, but migrate away soon, because this
function is about to disappear"
----
If you can't make this distinction, then you also run into the
danger of not breaking anybody's code when deprecating stuff, but
having to keep deprecated stuff around forever.
