Front page | perl.perl5.porters |
Postings from March 2023
Re: strictness and "use 5.whatever"
From: Graham Knop
March 8, 2023 12:41
Re: strictness and "use 5.whatever"
Message ID: CAM=m89Ena1anW5oarV0WLO-riyJSx1sdh-PsY89y_jFO8jhFkA@mail.gmail.com
On Wed, Mar 8, 2023 at 7:55 AM Zefram via perl5-porters
> 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.
> 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. The cost of making this
> change would be to break perfectly good existing programs that rely on,
> for example, "no strict; use 5.016;" being a valid preambla that provides
> a non-strict lexical status. That is not an unreasonable combination
> of declarations: there's nothing a priori wrong about stricture being
> declared before feature bundle. This preamble has been permitted and
> had its present meaning ever since the release of Perl 5.16.
> To thus change the meanings of "use 5.016;", "use 5.010;", and all the
> others, is directly contrary to the promise of stability implied by the
> use of an explicit version number. It's fine for "use 5.038;" to take
> precedence over a prior "no strict;", if it did so consistently from its
> earliest legality in Perl 5.38. But historical version numbers shouldn't
> change their meanings. (The situation is different for "use 5.012;"
> and "use 5.014;", which did take precedence over a prior "no strict;"
> in Perls 5.12 and 5.14, but then changed meaning in Perl 5.16. That's a
> historical mistake, but the 5.16 treatment should now probably stand.)
> This planned change would only cause gratuitous breakage of code that
> relied on the stability implied by using an explicit version number.
> Doing so would not only be wrong in itself, but it would also discredit
> that promise of stability, with respect to any version number, for the
> indefinite future. It would become understood that to reliably set up the
> lexical state requires explicitly stating the stricture and feature flags,
> because the version-number bundles are unstable. This would result in
> "use VERSION" becoming yet another of Perl's features that programmers
> of good taste eschew but which cause a core maintenance burden forever.
> 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.
> So, as with the situation regarding stricture flags, the future
> fatalisation of what is now deprecated would just be gratuitous breakage.
> A clean fatalisation of a particular combination of declarations is less
> bad than leaving them legal and just changing their meaning, but it's
> still an unjustified change that is contrary to the stability expectations
> of this type of declaration. Not only would the fatalisation do damage
> to the feature's reputation for stability, but some of that damage has
> already been done by means of the deprecation per se.
> Finally, what about the relationship between the deprecation and
> the planned future change in semantics? There pretty much isn't one.
> The thing that is currently deprecated and the thing that it is planned
> to change (which supposedly motivates the deprecation) not only are
> not the same thing, but have essentially no overlap. Things such as
> "no strict; use 5.016;", the meaning of which it is intended to change,
> are not deprecated, and deprecated things such as "use 5.016; use 5.010;"
> pose no difficulty for the planned change in stricture control. The two
> kinds of declaration combination are only quite loosely connected.
> So the deprecation doesn't support the change that supposedly motivates
> it, and it has no motivation of its own. It is misconceived.
> In my opinion, because neither the proposed semantic change nor
> the deprecation have good justification, both should be abandoned.
> The deprecation warning should be eliminated, and programmers who
> were affected by it should be advised to muffle the warning (which
> unfortunately can't be done any more specifically than the "deprecated"
> category). The documentation should stop warning about both future
> changes. Doing this before 5.38 would be the way to minimise the damage
> done by the bad decision in 5.36.
> If there is still some compelling reason to prohibit "use 5.016; use
> 5.010;", then this needs to be justified in its own right. Reference to
> a plan to change the treatment of stricture bits doesn't cover this issue.
> If there is still some compelling reason to stop supporting the current
> semantics of "no strict; use 5.016;", then it needs to be handled
> differently. It should not change to just have a different effect on the
> stricture bits, but rather, if the current meaning is not acceptable,
> this combination should become prohibited. Any change in meaning,
> whether to become prohibited or to be legal with a different meaning,
> should be preceded by a deprecation cycle, where the deprecation warns
> about the thing that's going to change meaning, not about an unrelated
> thing located nearby.
Discussion of the earlier implementation of strict and features being
enabled by a "use v5.xx":
Discussion of adding warnings and simplifying the meaning of "use v5.xx":
Proposal to remove implict strict tracking:
Proposal to deprecate version "downgrading":
PR to disable version "downgrading":