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

Re: strictness and "use 5.whatever"

Thread Previous | Thread Next
Graham Knop
March 8, 2023 12:41
Re: strictness and "use 5.whatever"
Message ID:
On Wed, Mar 8, 2023 at 7:55 AM Zefram via perl5-porters
<> 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.
> 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.
> -zefram

Relevant discussions:

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":

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