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

Re: on changing perl's behavior

Thread Previous | Thread Next
From:
Dan Book
Date:
March 27, 2021 21:32
Subject:
Re: on changing perl's behavior
Message ID:
CABMkAVUy49GRaE3MiXn9kiitcJmLFd71Ur1_H9vZdP=MoyZwzA@mail.gmail.com
On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> $* is a nice example because it's connected to so many changes, but it's
> not the only place we've changed defaults, either to deprecate things, to
> remove deprecated things, or to just change behavior.  (For example, the
> meaning of "scalar %hash" changed between v5.24 and v5.26.)  Some of these
> changes change runtime behavior of the code, some change the legal syntax
> of Perl.  The "only perl can parse Perl" rule will apply to these in
> different amounts.
>

They are nice examples for specific instances, but they each have their own
unique circumstances and aren't great for informing a "general case" of any
sort.

$* was used by almost nobody while it existed, for its part.

scalar %hash was already a weird return value, so even code that used it
rarely cared what it actually contained.

The current feature bundle contains: bitwise, current_sub, evalbytes, fc,
> indirect, postderef_qq, say, state, switch (good grief), unicode_eval, and
> unicode_strings.  I think some of these are things that should become
> default parts of the language.  It's helpful to people who write code to a
> recent version of perl only.  It makes it possible to eventually make the
> feature always-on.
>

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

-Dan

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