Front page | perl.perl5.porters |
Postings from March 2021
Re: on changing perl's behavior
From: H.Merijn Brand
March 29, 2021 11:58
Re: on changing perl's behavior
Message ID: email@example.com
On Sat, 27 Mar 2021 17:31:53 -0400, Dan Book <firstname.lastname@example.org> wrote:
> On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes
> <email@example.com> 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,
> > 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
Personally I am willing to accept these breaking changes
* as long as I have a way to make the script valid to run under all
versions I support *
I really like the soft-feature thingy proposed
I just recently ran into my first fail with unicode_strings, as tests
started to FAIL when I replaced a "use strict" with "use 5.14.2". That
specific test was testing all kind of strings with different encodings
to see how the module's functionality would cope with it.
For that specific file 'no "unicode_strings";' was sufficient to make
everything PASS again, but if a script needs syntax to disable new
functionality that would make it impossible to run in an older version,
that would make life harder to stay backward compatible.
So, new defaults: YES PLEASE! (but not if it is impossible to have
(parts of) the code run on older pers. Extra statements and conditions
are ok, as long as it is possible).
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org