Front page | perl.perl5.porters |
Postings from March 2023
Re: strictness and "use 5.whatever"
Thread Previous
|
Thread Next
From:
Paul "LeoNerd" Evans
Date:
March 8, 2023 12:00
Subject:
Re: strictness and "use 5.whatever"
Message ID:
20230308120032.5d326b8a@shy.leonerd.org.uk
On Wed, 8 Mar 2023 06:54:53 +0000
Zefram via perl5-porters <perl5-porters@perl.org> wrote:
> I have an opinion on a change that was made when I wasn't around: the
> deprecation and planned changes around the interaction of strictness
> and "use 5.whatever" are a bad idea. The actual planned changes are
> unjustified, and the deprecation doesn't match the planned changes.
>
> First I'll consider the intended changes. As I understand it, the
> intention is that in the future "use 5.whatever", for historical
> version numbers, will unconditionally set the lexical stricture
> status, either on or off, according to the version being requested.
> This is in contrast to the present situation, where such usage can
> turn strictures on, for some versions, but won't turn on strictures
> that have previously been explicitly turned off. This means that,
> for example, "no strict; use 5.016;", which currently turns
> strictures off, will instead turn them on, and "use strict; use
> 5.010;", which currently turns strictures on, will instead turn them
> off.
That was looked at by the PSC, and implemented by me.
As a very brief explanation: It's much simpler this way, both to
implement and to explain to users. See below.
> What is the purpose of this change? It wouldn't remove some facility
> that is onerous to maintain. The lexical stricture status will still
> exist. All it would change is the arrangement of declarations by
> which the strictures are controlled. The only things that could be
> removed as a result are the stricture-explicitly-set bits.
Yes. That was exactly one among the reasons why we wanted to change it.
We basically ran out of hints bits, and noticed that there are three
entire bits being used just as a shadow second copy of the three
currently-defined strictness bits. We'd quite like to get those bits
back as we're running out of them. In addition, if we ever add more
strictness controls later, would we have to add more second copies of
all of those?
Secondly, there's the ease with which it can be explained to users.
Ever since the ill-fated first attempt at "perl 7" came and died, we've
tried to put a much bigger emphasis on the importance of starting every
code file with an appropriate `use VERSION` declaration. Starting at
perl 5.36 a `use VERSION` will now also act as `use warnings`, and as
soon as 5.39 starts development and we can declare parts of
`use builtin` as stable then that'll gain version bundles much like
`use feature` does, and they will be implied by a `use VERSION` as well.
Thus, *with this change in strict in place*, we can confidently tell
users that
use v5.40;
is really exactly equivalent to
use strict;
use warnings;
use feature ':5.40';
use builtin ':5.40';
It's a simple model for us to create, test, verify, and for users to
understand and use. Whereas, under the previous set of semanitcs that
wasn't the case - it's exactly equivalent for warnings/feature/builtin
but not for strict. The equivalent code for strict isn't possible to
write down exactly because of the complex interaction between the
implicit and the explicit shadow bits.
...
> Next, I'll look at the deprecation per se. The deprecated thing is
> having a "use 5.010;" shadow a prior "use 5.016;" or other use with a
> higher version number. As with the above, this is not actually
> enabling the removal of anything problematic, but only tinkering with
> the way that lexical state gets declared. As with the above, "use
> 5.016; use 5.010;" is not an a priori unreasonable combination of
> declarations: we generally permit lexical declarations to shadow
> earlier ones, taking effect in a narrower scope. And as with the
> above, this combination of declarations has been legal and had its
> present meaning as long as those declarations have individually been
> legal.
Offhand while I write this I can't remember what the reason for
disallowing back-stepping was, but I recall it had something again to
do with arrangements around feature or hints bits. If it is still of
interest I can attempt to reread the various changes and commit
messages and see if it refreshes anything in my mind.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next