My Favorite Warnings: deprecated

By Tom Wyant on

The deprecated warning is a grab-bag. Basically, anything that is deprecated causes this warning to be generated, and the list changes from release to release.

The only reason I can think of ever to turn this off is around a deprecated construction while you are actively working to eliminate it. Silencing it and then forgetting about it will bite you, eventually.

For the curious (and to run my word count, since otherwise this would be a really short blog entry), the current list of deprecations according to the 5.34.0 perldiag is:

do "%s" failed, '.' is no longer in @INC; did you mean do "./%s"?
. (the current directory) was removed from @INC in Perl 5.26.

Use of "goto" to jump into a construct is deprecated

This has been deprecated since Perl 5.12. No word that I know of on when it will actually be removed.

Use of '%s' in \p{} or \P{} is deprecated because: %s

This is emitted for deprecated Unicode properties. The only timetable on these is that they will be removed from Perl when the Unicode Consortium removes them from Unicode. Be warned.

Use of tainted arguments in %s is deprecated

This message is issued by system() and exec() when you feed them tainted arguments. No word that I know of on when this will become fatal, but I am surprised it is not already.

Previous entries in this series:

  1. A Belated Introduction
  2. once
  3. redundant and missing
  4. exiting
  5. uninitialized
  6. redefine
  7. Ex-Warnings

2 Comments

Author Profile Page Aristotle | November 20, 2021 11:59 AM | Reply
No word that I know of on when it will actually be removed.

From the perlpolicy definition of “deprecated”:

If something in the Perl core is marked as deprecated, we may remove it from the core in the future, though we might not.

Lived reality on p5p doesn’t always align with the original intention of the policy, but that intention is outlined earlier in the same section:

Existing syntax and semantics should only be marked for destruction in very limited circumstances. If they are believed to be very rarely used, stand in the way of actual improvement to the Perl language or perl interpreter, and if affected code can be easily updated to continue working, they may be considered for removal. When in doubt, caution dictates that we will favor backward compatibility. When a feature is deprecated, a statement of reasoning describing the decision process will be posted, and a link to it will be provided in the relevant perldelta documents.
Author Profile Page Tom Wyant | November 20, 2021 6:15 PM | Reply

Thanks. Features can also be removed if it turns out they present a security issue, such as . in @INC.

Leave a comment

About Tom Wyant

user-pic I blog about Perl.

More info »