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

Re: on changing perl's behavior

Thread Previous | Thread Next
Dan Book
March 27, 2021 21:51
Re: on changing perl's behavior
Message ID:
On Sat, Mar 27, 2021 at 5:31 PM Dan Book <> wrote:

> On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes <>
> 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

And to add to this a few things which are not features but have been
considered for the same honor:

*strict: Breaks working code. I don't see a reasonable path to make this
happen aside from deprecating all non-strict syntax for strict 'subs' and
'vars', but strict 'refs' operates at runtime.
*warnings: Well, warnings are an interesting case. They are already enabled
by default, just only certain ones we decided were worth doing that for. I
suggest reading through if you aren't
familiar with the organization of Perl warnings. Instead of a blanket "make
all warnings default" maybe we should be considering if some of the ones
that aren't should be moved there.
*utf8: A path for this was outlined by Zefram (
and roughly requires a deprecation period for non-ascii bytes in source
code outside of "use utf8".


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