On Tue, Feb 24, 2015 at 09:55:28AM -0800, Jonathan M Davis via Digitalmars-d-learn wrote: [...] > Regardless, when a symbol is either marked as "scheduled for > deprecation" in the docs or outright deprecated, a date is usually put > in the docs for when it will be moved to the next deprecation stage, > though in the case of "scheduled for deprecation," there's a decent > chance that it'll be marked with the next release number rather than a > date, since the idea there is to give folks a release of leeway so > that they can avoid deprecation messages when building with master > rather than give them a particular period of time to change their code > before the symbol goes away, as is the case with symbols that are > actually deprecated. [...]
What about Walter's recent complaint that certain old symbols have gone away and no upgrade path was presented to the user, just an inscrutible error message? I thought the consensus from that discussion was to leave deprecated symbols undocumented but still defined (even if it's just a no-op stub with a deprecation message or static assert pointing the user to the new symbol(s)). T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
