stevieb has asked for the wisdom of the Perl Monks concerning the following question:

The experiments and deprecation regime for perl core has changed significantly over the years which is a great thing. I'm wondering if it has been considered to create a new CLI flag to determine within files whether either one are being used without exercising the code (like the -c flag for syntax).

I thought about writing a Test:: module for this, but after only about 15 minutes, realized that it would be nearly futile without both very excessive build prereqs and nearly impossible-to-keep-updated trickery. I do think it would be a nice feature to have, to be able to throw a list of files at perl blead and see if any of one's modules within it may require changes before the next public release without having to actually ensure 100% test coverage, and rebuilding/testing all your modules/scripts prior to each one.

Is this something reasonable, or am I over-thinking again?

Update: for those who aren't aware, perl blead is the most recent build of core perl's development code, always in an odd version number. Currently, blead is 5.23, in prep for the public release of 5.24. blead == trunk/master etc.

Replies are listed 'Best First'.
Re: Could perl have a "do these files contain experimental/deprecated features" flag?
by shmem (Chancellor) on Oct 19, 2015 at 21:49 UTC

    Isn't that already covered by the deprecated | experimental warning categories?

    qwurx [shmem] ~> perl -wcle '$[=1' Use of assignment to $[ is deprecated at -e line 1. -e syntax OK

    Of course, deprecations that become apparent only at runtime cannot be checked at compile time.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
Re: Could perl have a "do these files contain experimental/deprecated features" flag?
by BrowserUk (Patriarch) on Oct 19, 2015 at 21:52 UTC

    According to this many/most experimental features already produce warnings.

    But I have to say that I wonder what you would do with the information produced by such a flag.

    • If this is your own module; you presumably thought about the implications when you chose to use the construct.

      Are you going to change your mind and remove it?

    • If this is someone else's module:

      would you refuse to use it because they've chosen to use an experimental feature?

    There are several experimental features I've simply refused to use because it was too confusing to understand their syntax rules; or too unreliable in use: eg. smartmatch.

    But if I found a module that did something I needed to do; but noticed it used smartmatching to do it; that wouldn't stop me using it provided it appeared to work correctly.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Could perl have a "do these files contain experimental/deprecated features" flag?
by Anonymous Monk on Oct 19, 2015 at 22:48 UTC