develooper Front page | perl.perl5.porters | Postings from May 2015

Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB

Thread Previous | Thread Next
From:
Ricardo Signes
Date:
May 6, 2015 13:27
Subject:
Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB
Message ID:
20150506132647.GA2728@cancer.codesimply.com
* Dave Mitchell <davem@iabyn.com> [2015-05-05T11:33:21]
> I think it's correct that it should dis-allow array refs etc, but I think
> undef should be re-allowed for 5.22.

I wrote many, many long responses to this, each one different than the
previous, as I reached logical dead ends.  The behavior and intent of
prototypes is, in my opinion, so incoherent as to make any reasoning from first
principles unlikely to bear fruit.

So, instead, I think we have a really simple choice.  Here's what the docs say
about (&):

  An "&" requires an anonymous subroutine, which, if passed as the first
  argument, does not require the "sub" keyword or a subsequent comma.

The old behavior allows:

  sub takes_sub (&) { ... }
  takes_sub(undef);

...which contradicts the documentation.  We should change the behavior or we
should change the documentation.

Changing the documentation and leaving the code alone (relative to v5.20) will
let things like BDB continue to work, where a literal undef is passed to reset
a stored subroutine.

Changing the code and leaving the documentation alone (again, relative to
v5.20) will break anything that had relied on this behavior, but will expose
bugs where a literal undef had been passed to a subroutine with a (&)
prototype in effect.  It will now issue a compile-time error.  Presumably,
these situations are bugs iff later something attempts $arg->(), which would
currently be a runtime error.  That doesn't mean that this wouldn't expose
existing bugs, but I think it does cut down on what we'd expect to see fixed.
Also, we should consider the prevention of future bugs, which won't ever need
to be detected at runtime.

Nonetheless, it is with heavy heart that I think I agree with the suggested
course of action:  go back to the old, worse behavior.  If we were starting
from scratch, I would hold my ground, but I don't think the breakage is
justified here.

Boy, do I ever dislike prototypes!

If anybody wants to change my mind, do so quickly! ;)  Or wait to try again in
5.23, I suppose...

-- 
rjbs

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About