Deprecation is an essential part of language and SDK maintenance. If you find a programming language that hasn’t done it, you’ve found a trivial or dead language. (Or one that’s just gone ahead and removed the features without any warning.)
Where did I say anything to the contrary? By all means, deprecate, by all means talk about it. Do not, however, put those messages in the output when I run a program. I don't even want it there on install but at least that's defensible in some way.
Neither of those can tell you where you’re using the now deprecated feature.
I guess you would be happy with a runtime warning that must be ENabled with a flag and documentation of that flag in the release notes.
I fear many users wouldn’t learn about the flag because they don’t read release notes (and yes, that would be a sorry state of affairs), and thus only would learn about it when the feature is removed (in this case because their program would error out, but for other breaking changes, it could ‘happily’ run, but with changed behavior)
> Neither of those can tell you where you’re using the now deprecated feature.
Do you not run tests? Know how to grep?
> I guess you would be happy with a runtime warning that must be ENabled with a flag and documentation of that flag in the release notes.
Yes, I would, as someone who reads changelogs, READMEs and blog posts before upgrading the interpreter, and who wants the only output of running the interpreter to be a direct consequence of the code I run, not hand-holding for people who are sloppy.
If individual deprecation warnings have to be specifically enabled, people who don’t read release notes describing them won’t search their source code for possible future problems, and their tests won’t signal any issues before a feature is removed, or (possibly, for other deprecations) behavior is silently changed. Deprecation would be worth zero for such users.
