It breaks existing code and is yet another non-backwards compatible
change, is against perlpolicy, and was done for no comprehensible reason.
Wow. Wrong, wrong and wrong!

1. It didn't break any code. Your code successfully threw an error on
deprecations as requested. If you don't want deprecations to throw an
error, don't ask Perl to do it!
That's a non-sequitur: the breakage here is the extra warning, not the fact
that it is made fatal. In environments which check for empty stderr to check
for errors, this breaks any script that uses warnings non-fatally.

Fatality is not breaking backwards compatibility further.

Furthermore, deprecating something is not done to warn people about
dangerous constructs, it's done to remove functionality later, which is
then another backwards compatible change.
2. Non-backwards compatible changes are not against policy.
I agree - Of course, the goal of deprecating things is to remove them
later, so no matter what, this is about breaking backwards compatibility.

A backwards compatible change would be a new warning category that users
can enable, and not deprecating this feature at all.
3. It was done for a very easy to comprehend reason.
Maybe, but the requirement is for the reason to be rational and strong
enough to outweigh the breakage, which is clearly not the case here.

For example, Lukas Mai gave "This will break one of my programs." as
reason. This is easy to understand, but without any merit, of course.
What? It's a compile-time warning.
Yes, it is a compile time warning. You seem to think that changes
something - what?
It doesn't takes 100% coverage to find a compile-time warning. In fact, it
requires absolutely no coverage.
I am not sure you understand Perl well enough here - Perl doesn't compile
all code before running your program (it is impossible), so you do need
100% coverage - code that isn't compiled, will not be tested.

Besides, you are ignoring the other arguments I quoted, as well as other
parts in perlpolicy I haven't quoted, for example:

    Existing syntax and semantics should only be marked for destruction in
    very limited circumstances. If a given language feature's continued
    inclusion in the language will cause significant harm to the language
    or prevent us from making needed changes to the runtime, then it may be
    considered for deprecation.

Where is the signifcant harm caused by this feature? This change is just
a political change: some p5pers don't like the syntax, so it has to go,
whether it causes signifcant harm or not doesn't matter.


    Any language change which breaks backward-compatibility should be able
    to be enabled or disabled lexically. Unless code at a given scope
    declares that it wants the new behavior, that new behavior should be

That should be easily possible here. Also, the documented standard is much
higher than you and others assume:

     Historically, we've held ourselves to a far higher standard than
     backward-compatibility -- bugward-compatibility. Any accident of
     implementation or unintentional side-effect of running some bit
     of code has been considered to be a feature of the language to be
     defended with the same zeal as any other feature or functionality. No
     matter how frustrating these unintentional features may be to us as we
     continue to improve Perl, these unintentional features often deserve
     our protection. It is very important that existing software written
     in Perl continue to work correctly. If end-user developers have
     adopted a bug as a feature, we need to treat it as such.

I haven't seen you addressing these discrepancies at all.

                 The choice of a Deliantra, the free code+content MORPG
       -----==- _GNU_ http://www.deliantra.net
       ----==-- _ generation
       ---==---(_)__ __ ____ __ Marc Lehmann
       --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
       -=====/_/_//_/\_,_/ /_/\_\

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase