develooper Front page | perl.perl5.porters | Postings from March 2021

Re: on changing perl's behavior

Thread Previous | Thread Next
Paul "LeoNerd" Evans
March 27, 2021 22:51
Re: on changing perl's behavior
Message ID:
On Sat, 27 Mar 2021 17:31:53 -0400
Dan Book <> wrote:

> We can split the features into roughly two categories: features that
> change the meaning of existing constructs, and features that add new
> keywords (which could clash with custom subs or keywords).
> Changing behavior:
> *bitwise: splits "smart" bitwise operators into two sets, potential to
> break any code using these operators, difficult to determine if it
> has been broken
> *indirect: we'd want to remove this, it's already default; but doing
> so would break a lot of existing code and the nature of the parser
> change makes it difficult to warn nicely about
> *unicode_eval: changes the behavior of string eval to make it more
> consistent, but existing string evals could be relying on the
> inconsistent interpretation
> *unicode_strings: similar to unicode_eval but much more wide reaching
> risk for a variety of string operations
> *postderef_qq: would break currently valid strings
> In my opinion, none of these are reasonably doable as it stands
> currently, aside from deprecating the behavior that they would change.
> New keywords:
> *current_sub: probably the lowest risk/highest reward of the
> features, use of the token __SUB__ outside of this feature is
> unlikely, but possible *evalbytes: adds the evalbytes keyword, low
> risk but not commonly used anyway
> *fc: adds the fc keyword, both useful and risky
> *say: useful and very risky
> *state: useful and very risky

I think another potentially useful way to split these changes is to
consider whether they are detectable at compile time, vs runtime; and
of those runtime ones which are potentially warnable, vs ones that
simply silently create the wrong answer.

For instance, getting rid of $* as a variable means that any code which

  $* = 1;

simply does not compile, which is a fast, noisy failure. Of the kinds
of failure that is the one we'd most like to have.

In the middle ground is __SUB__, because as Dan points out it's
slightly possible that maybe someone has defined it as a function
elsewhere and if they did so maybe our code would compile fine; but
we'd likely discover at runtime that it didn't yield a CODE reference
so would fail with some sort of complaint about not being invokable.

Finally the bitwise operators are that final set, where if we happen to
pick the wrong one then it's unlikely a warning happens even at
runtime. The program silently continues and just produces incorrect

While I don't think I'd say we "can easily" make any sort of
non-backward compatible change very lightly, we can certainly consider
this classification when deciding if the change is justified. I'd feel
happier about making changes that would cause existing programs to fail
to *compile* and give obvious error messages, and less happy about ones
that cause silent changes in behaviour to the running of
otherwise-valid ones.

Possibly this bias comes from the fact that I'm a big fan of
unit-testing everything - from the smallest of helper modules up to the
largest of full-scale systems. Everything I run at the very least has a
t/00use.t which checks if every file is `use_ok()`. This means I bias
towards putting a lot of faith in compiletime checking. If we deprecate
or remove features that the compiler can warn about in these files, I
would feel more comfortable about them.

Paul "LeoNerd" Evans      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About