Deprecation plans

Hi everyone,


During the core hackathon in Amsterdam, we had a large discussion[1] on
deprecations. This resulted in two decisions:

* From now on, deprecations must include a version in which the
deprecation will take effect. This is to avoid the current situation in
which there are numerous deprecations still in the code, some over 10,
15, or 20 years old.

* Every current existing deprecation must either be pinned with an
effective version or be undeprecated.


During the discussion we went over all existing deprecations and made a
collective decision on both, while trying to remain both practical and
lenient where appropriate. I present the decisions we made. Abigail is
currently working on putting these all into work prior to 5.25.9. A big
thank you to everyone who attended this grueling Hunger Games of
deprecated features and syntaxes, and to Abigail for the work on leading
this and making it a reality. :)


The list:

* Attribute "locked" is deprecated: Deprecated in 5.12.0, delete in 5.28.

* Attribute "unique" is deprecated: Deprecated in 5.12.0, delete in 5.28.

* Calling POSIX::%s() is deprecated: Removing from perldiag.

* Constants from lexical variables potentially modified elsewhere are
deprecated: Delete in 5.32.

* Deprecated use of my() in false conditional: Deprecated in 5.10.0,
remove in 5.30.0.

* ${^ENCODING} is no longer supported: Partially deprecated in 5.22.0,
fully deprecated in 5.25.3, fatal in 5.28.

* $* is no longer supported: Functionality removed in 5.10.0, removing
the warning.

* $# is no longer supported: Functionality removed in 5.10.0, removing
the warning.

* Opening dirhandle %s also as a file: Deprecated in 5.10.0, fatal in 5.28.

* Opening filehandle %s also as a directory: Deprecated in 5.10.0, fatal
in 5.28.

* Passing malformed UTF-8 to "%s" is deprecated: Deprecated since
5.18.0, fatal in 5.25.9.

* Setting ${^ENCODING} is deprecated: Deprecated in 5.22.0. Remove text.

* Setting $/ to a reference to %s as a form of slurp is deprecated,
treating as undef: Deprecated in 5.20.0, fatal in 5.28.

* Unescaped left brace in regex is deprecated here, passed through in
regex; marked by S<<-- HERE> in m/%s/: Deprecated in 5.25.2, fatal in 5.30.

* Unknown charname '' is deprecated: Deprecated since 5.24.0, remove in
5.28.0.

* Use of assignment to $[ is deprecated: Deprecated in 5.12.0; list
context deprecated in 5.14.0, fatal in 5.28 (unless you use arybase)

* Use of bare << to mean <<"" is deprecated: Deprecated in 5.000, remove
in 5.28.0.

* Use of code point 0x%s is deprecated; the permissible max is 0x%s:
Deprecated since 5.24.0, remove in 5.28.

* Use of comma-less variable list is deprecated: Remove in 5.28.

* Use of *glob{FILEHANDLE} is deprecated: Deprecated in 5.8,
undeprecated in 5.24.0, remove from perldiag.

* Use of "goto" to jump into a construct is deprecated: Deprecated in
5.12.0, remove in 5.28.0.

* Use of inherited AUTOLOAD for non-method %s() is deprecated:
Deprecated since 5.004, remove in 5.28.

* Use of %s is deprecated: Remove text.

* Use of %s on a handle without * is deprecated: Remove text.

* Use of strings with code points over 0xFF as arguments to %s operator
is deprecated: Deprecated in 5.24.0, removed in 5.28.0.

* dump() better written as CORE::dump(): Make it a deprecation warning;
dump no longer available in 5.30.

* File::Glob::glob(): Deprecated in 5.8, add deprecation warning in
5.25.9, remove in 5.30.

* "L<section>": Deprecated in 5.12.0.

* "%s" is more clearly written simply as "%s": Deprecated in 5.14.0,
removed in 5.28.

* Don't read the Unicode data base files in F<lib/unicore>: Deprecated
in 5.16.0, no action for now.

* "--libpods" in Pod::Html: Warn since 5.18.0, remove in 5.26.

* sysread(), syswrite(), recv() and send() are deprecated on :utf8
handles: Deprecated in 5.24.0, remove in 5.30.

* $! vs $^E for Winsock functions: Deprecated in 5.24.0, put in
perlport, no action for now.

* Utils: c2ph, pstruct: Deprecated in favor of h2xs, gone in 5.26.0.

* %SIG: Undeprecate.

* B::OP::terse: Remove in 5.28.0.


[1] This included Abigail, Yves Orton, Dave Mitchell, Karl Williamson,
Nicholas Clark, Ilmari, Leon Timmermans, Aaron Crane, Matthew Horsfall,
Lukas Mai, Tux, Nicolas (Atoomic) Rochelemagne, Todd Rinaldo, John
Lightsey, Nick Koston, Stevan Little, and myself. (This is out of memory
and a bit of checking. I apologize if I forgot anyone.)
0
xsawyerx
1/8/2017 6:22:55 PM
perl.perl5.porters 46379 articles. 0 followers. Follow

21 Replies
89 Views

Similar Articles

[PageSpeed] 47

> On Jan 8, 2017, at 12:22 PM, Sawyer X <xsawyerx@gmail.com> wrote:
> 
> * From now on, deprecations must include a version in which the
> deprecation will take effect. This is to avoid the current situation in
> which there are numerous deprecations still in the code, some over 10,
> 15, or 20 years old.
> 
> * Every current existing deprecation must either be pinned with an
> effective version or be undeprecated.

This is fantastic.  Thank you all for doing this.

--
Andy Lester => www.petdance.com
0
andy
1/9/2017 7:29:38 PM
On Sun, Jan 08, 2017 at 07:22:55PM +0100, Sawyer X wrote:
> * sysread(), syswrite(), recv() and send() are deprecated on :utf8
> handles: Deprecated in 5.24.0, remove in 5.30.

Should these fail, or switch to working in bytes?*

Tony

*using SvPVbyte() for syswrite() and send()
0
tony
1/9/2017 10:14:58 PM
On Sun, Jan 8, 2017 at 7:22 PM, Sawyer X <xsawyerx@gmail.com> wrote:

> * $* is no longer supported: Functionality removed in 5.10.0, removing
> the warning.
>
> * $# is no longer supported: Functionality removed in 5.10.0, removing
> the warning.
>
> [...]
>
> * Use of assignment to $[ is deprecated: Deprecated in 5.12.0; list
> context deprecated in 5.14.0, fatal in 5.28 (unless you use arybase)

Yes to deprecating all of these, but why are we treating the
deprecation of $* / $# differently from $[ ?

I.e. once the warning is removed from the former two will be freed up
for use as normal variables, whereas that won't happen with $[
which'll be made fatal.

Shouldn't we be consistent here and either make all previously magical
variables listed in perlvar either not special at all (as seems to be
the plan with $* & $#), or reserve them forever by making their use
fatal as is the plan with $[?

My bias would be to just make them all fatal, despite all these old
deprecation warnings someone will dig up an old script / blogpost /
Matt's Script Archive entry and try to execute it, I think it would be
more helpful to just die in those cases instead of introducing subtle
behavior differences.

But maybe not and we should just un-magic them, but in that case why
only un-magic some but not others?
0
avarab
1/10/2017 11:05:39 AM
--EVF5PPMfhYS0aIcm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Cool, thanks for working on this!  A few notes:

* Sawyer X <xsawyerx@gmail.com> [2017-01-08T13:22:55]
> * Deprecated use of my() in false conditional: Deprecated in 5.10.0,
> remove in 5.30.0.

This came up in the past and "remove" seemed like not the straightforward a=
nd
preferred solution:

  http://markmail.org/thread/uslcig4mwn47pmyn

I am not presenting an opinion, only a link to history.

> * Use of assignment to $[ is deprecated: Deprecated in 5.12.0; list
> context deprecated in 5.14.0, fatal in 5.28 (unless you use arybase)

How does this interact with the array_base feature?  array_base continues to
work as it does now, implicitly loading arybase when $[ is used?

> * Use of inherited AUTOLOAD for non-method %s() is deprecated:
> Deprecated since 5.004, remove in 5.28.

I have quite a few times beaten the drum of "caller should be able to tell =
you
whether something was called as a method."  I want to pretend that this rem=
oval
is somehow releated to getting that feature added... ;)

> * dump() better written as CORE::dump(): Make it a deprecation warning;
> dump no longer available in 5.30.

What about CORE::dump()?  I never use it, but I know some folks use it as a
breakpoint in gdb or something?  That has come up in the past.

--=20
rjbs

--EVF5PPMfhYS0aIcm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJYdXDkAAoJEOYby6cMccU5pI4IANFgeaNPAxEuxFcw3IOEZzHL
NgB9IQqrC5HegiYjal99Bw1BlL7IY2OQ6k3me9yuweNAWtljxudx+FR5eVECePnZ
TK9SWMvX5zLYbnIk0PVsReJ5vRUVWW+pu8VA0UGypyPbZFMlmye7aJhiCxUK8QmH
uy26zX+4vkp8NYVHTe7vjfVkdni1ccAD2fEkWbO4sLne7L2QsAL+BWav0TtgXb95
nwRilOCT5ba5WG6EnWlLDuGgBeQ8mVAZwWP8VfP4NJf986rHTjGl+TELUbSMSZp4
S3+WYTXX1SuXrWkFxyoyYGED6uMHVKKcKgaw04Vx6FpLB1u1iJuT0YQ9ou51xrQ=
=sdoS
-----END PGP SIGNATURE-----

--EVF5PPMfhYS0aIcm--
0
perl
1/10/2017 11:40:20 PM
Ricardo Signes wrote:
>What about CORE::dump()?  I never use it, but I know some folks use it as a
>breakpoint in gdb or something?

It has no particular value there.  If it's desired to have a breakpoint
that's explicitly invokable from Perl code, one can use the actual
debugger breakpoint facility to break on pp_study or some other
rarely-called op.

-zefram
0
zefram
1/10/2017 11:51:21 PM
Sawyer X wrote:
> * Constants from lexical variables potentially modified elsewhere are
> deprecated: Delete in 5.32.

This is an instance where buggy behaviour is grandfathered in, to ease
a bug-fixing transition.  I assume 'delete' means delete the special
case in the code that retains the bug, and switch over to making a non-
constant routine (the correct behaviour).

> * ${^ENCODING} is no longer supported: Partially deprecated in 5.22.0,
> fully deprecated in 5.25.3, fatal in 5.28.

Do we have any precedent for making the setting of an ideally nonexis-
tent variable fatal?  Should this not be just like $* and $# (remove
the warning)?

> * Setting $/ to a reference to %s as a form of slurp is deprecated,
> treating as undef: Deprecated in 5.20.0, fatal in 5.28.

How is the value of $/ gets affected when an assignment thereto croaks?

> * Use of "goto" to jump into a construct is deprecated: Deprecated in
> 5.12.0, remove in 5.28.0.

I have a strong objection to this one.  (I have code relying on it
that would likely get slower if I had to rewrite it to avoid the con-
struct.  Also, some instances of this do not get the warning.)

The two reasons that were given when this deprecation was proposed
were (1) that it would not work with the 'code generation' patch
that later was rejected as not providing any more efficiency, while
increasing memory usage, and (2) that this kind of goto did not work
with 'given' blocks.

The former reason no longer applies.  The latter reason applies to an
experimental feature.

I propose we undeprecate this feature instead.

> * Use of inherited AUTOLOAD for non-method %s() is deprecated:
> Deprecated since 5.004, remove in 5.28.

Phew! Finally!

> * dump() better written as CORE::dump(): Make it a deprecation warning;
> dump no longer available in 5.30.

Does that mean dump() without CORE:: will be deprecated?
0
sprout
1/11/2017 6:06:24 AM
On Wed, Jan 11, 2017 at 7:06 AM, Father Chrysostomos <sprout@cpan.org> wrote:
> Sawyer X wrote:
>> * Constants from lexical variables potentially modified elsewhere are
>> deprecated: Delete in 5.32.
>
> This is an instance where buggy behaviour is grandfathered in, to ease
> a bug-fixing transition.  I assume 'delete' means delete the special
> case in the code that retains the bug, and switch over to making a non-
> constant routine (the correct behaviour).

We've gone from:

 * Always creating const routines on *$k = sub () { $v }
 * Only creating const routines on *$k = sub () { $v } if $v is
referenced once before, otherwise non-constant

Do you mean we should only create them on *$k = sub () :const { $v }?
That sounds fine, but shouldn't we also retain & expand the warning to
the second of the two cases above to alert users that that pattern no
longer creates constants?
0
avarab
1/11/2017 10:42:15 AM
On Tue, Jan 10, 2017 at 12:05:39PM +0100, �var Arnfj�r� Bjarmason wrote:
> > * $* is no longer supported: Functionality removed in 5.10.0, removing
> > the warning.
> >
> > * $# is no longer supported: Functionality removed in 5.10.0, removing
> > the warning.
> Shouldn't we be consistent here and either make all previously magical
> variables listed in perlvar either not special at all (as seems to be
> the plan with $* & $#), or reserve them forever by making their use
> fatal as is the plan with $[?
> 
> My bias would be to just make them all fatal, despite all these old
> deprecation warnings someone will dig up an old script / blogpost /
> Matt's Script Archive entry and try to execute it, I think it would be
> more helpful to just die in those cases instead of introducing subtle
> behavior differences.

+1

-- 
More than any other time in history, mankind faces a crossroads. One path
leads to despair and utter hopelessness. The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
    -- Woody Allen
0
davem
1/11/2017 12:15:14 PM
On Tue, Jan 10, 2017 at 06:40:20PM -0500, Ricardo Signes wrote:
> Cool, thanks for working on this!  A few notes:
> 
> * Sawyer X <xsawyerx@gmail.com> [2017-01-08T13:22:55]
> > * Deprecated use of my() in false conditional: Deprecated in 5.10.0,
> > remove in 5.30.0.
> 
> This came up in the past and "remove" seemed like not the straightforward and
> preferred solution:
> 
>   http://markmail.org/thread/uslcig4mwn47pmyn
> 
> I am not presenting an opinion, only a link to history.

The longer history of this is that back in feb 2004, I added a general
deprecation warning for any 'my $foo if condition' style code - given that
it was likely to trigger the buggy 'lexical var not cleared on scope
exit and old value still available on next call' behaviour:

    commit dc9aa44637d2171ba3efbf36c71e8591a7ce05d7
    commit edd7382e985077dac6582d6406b3a16fa5fff0e9

Then in these 2004 threads:

    http://nntp.perl.org/group/perl.perl5.porters/88928
    http://nntp.perl.org/group/perl.perl5.porters/89114

it was found that the new warning made CPAN *very* noisy, and also that it
was buggy: it missed warning on some cases.

So I replaced it with the more restrictive 'Deprecated use of my() in
false conditional', which only warned on a *compile-time* false, i.e.
specifically 'my $x if 0', so that it would discourage people from
exploiting the bug to implement poor-man's state vars. So if we ever fixed
or changed the buggy behaviour, people would be less likely to be relying
on that behaviour.

    commit 7921d0f22732c0609e6c9d21be9aaf6e52f99e6b

From that perspective, I see no problem in making any compile-time
situations where it currently warns into compile-time croaks.

If we ever fix or change the behaviour, then we could remove the croak.

As for fixing it, that's quite hard. At one point long ago I had a
proof-of-concept fix that essentially moved the run-time behaviour of each
my() to the top of each scope; so this code:

    {
        ...
        my $x = 1;
        ...
        my $y = 2;
        ...
    }

would behave at runtime (but without changing the compile time scope of
each var) conceptually like

    {
        (my $x, $y,....);
        ...
        $x = 1;
        ...
        $y = 2;
        ...
    }

This worked. The issue with it was that in some circumstances it could
impose a significant performance penalty. Consider:

    while (<>) {
        next unless /(some)_(rare)_(occurrence)/;
        
        # lots of code to process these rare lines:

        my ($some, $rare, $occurrence) = ($1, $2, $3);
        ...
        my ($a, $foo, @b, %c);
        ...
        my ($even, $more, $lexicals); # stuff further down the block
        ...
    }

Previously the loop was fast because it only has to make a note on the
savestack to clear variables when the rare line is hit. Now it always has
to do it for every line.

It's analogous to this old behaviour:

    while (<>) {
        next unless /(some)_(rare)_(occurrence)/;
        local($some, $rare, $occurrence) = ($1, $2, $3);
        local($a, $foo, @b, %c);
        local($even, $more, $lexicals);
        ...
    }

being changed to this:

    while (<>) {
        local($some, $rare, $occurrence);
        local($a, $foo, @b, %c);
        local($even, $more, $lexicals);
        next unless /(some)_(rare)_(occurrence)/;
        ($some, $rare, $occurrence) = ($1, $2, $3);
        ...
    }

If we *were* to change the behaviour, then we'd probably need a further
deprecation and warning cycle to cover some of the other cases where a my
is being skipped at runtime - i.e. something like my original reverted
commit. Perhaps CPAN would be less noisy these days.




-- 
This is a great day for France!
    -- Nixon at Charles De Gaulle's funeral
0
davem
1/11/2017 2:11:23 PM

On 01/11/2017 01:15 PM, Dave Mitchell wrote:
> On Tue, Jan 10, 2017 at 12:05:39PM +0100, �var Arnfj�r� Bjarmason wrote:
>>> * $* is no longer supported: Functionality removed in 5.10.0, removing
>>> the warning.
>>>
>>> * $# is no longer supported: Functionality removed in 5.10.0, removing
>>> the warning.
>> Shouldn't we be consistent here and either make all previously magical
>> variables listed in perlvar either not special at all (as seems to be
>> the plan with $* & $#), or reserve them forever by making their use
>> fatal as is the plan with $[?
>>
>> My bias would be to just make them all fatal, despite all these old
>> deprecation warnings someone will dig up an old script / blogpost /
>> Matt's Script Archive entry and try to execute it, I think it would be
>> more helpful to just die in those cases instead of introducing subtle
>> behavior differences.
> +1

I reckon this was an oversight. I'm also in favor of making them all fatal.

Any objections?
0
xsawyerx
1/14/2017 4:36:52 PM

On 01/11/2017 07:06 AM, Father Chrysostomos wrote:
> Sawyer X wrote:
>> * Constants from lexical variables potentially modified elsewhere are
>> deprecated: Delete in 5.32.
> This is an instance where buggy behaviour is grandfathered in, to ease
> a bug-fixing transition.  I assume 'delete' means delete the special
> case in the code that retains the bug, and switch over to making a non-
> constant routine (the correct behaviour).
>
>> * ${^ENCODING} is no longer supported: Partially deprecated in 5.22.0,
>> fully deprecated in 5.25.3, fatal in 5.28.
> Do we have any precedent for making the setting of an ideally nonexis-
> tent variable fatal?  Should this not be just like $* and $# (remove
> the warning)?

The plan with $[ is to make it Fatal. AEvar raised the notion that $*
and $# are inconsistent in that way and suggested we make them fatal as
well. I think that's a good idea. That means ${^ENCODING} will follow suit.

>
>> * Setting $/ to a reference to %s as a form of slurp is deprecated,
>> treating as undef: Deprecated in 5.20.0, fatal in 5.28.
> How is the value of $/ gets affected when an assignment thereto croaks?

Do you mean in case of eval{} ?

>
>> * Use of "goto" to jump into a construct is deprecated: Deprecated in
>> 5.12.0, remove in 5.28.0.
> I have a strong objection to this one.  (I have code relying on it
> that would likely get slower if I had to rewrite it to avoid the con-
> struct.  Also, some instances of this do not get the warning.)
>
> The two reasons that were given when this deprecation was proposed
> were (1) that it would not work with the 'code generation' patch
> that later was rejected as not providing any more efficiency, while
> increasing memory usage, and (2) that this kind of goto did not work
> with 'given' blocks.
>
> The former reason no longer applies.  The latter reason applies to an
> experimental feature.
>
> I propose we undeprecate this feature instead.

I suggest we discuss it in a separate thread.

The policy I have in mind for these are: If you have a use-case for
this, which is reasonable, and to which there is no alternative, then we
should either create one or undeprecate.

>> * dump() better written as CORE::dump(): Make it a deprecation warning;
>> dump no longer available in 5.30.
> Does that mean dump() without CORE:: will be deprecated?

This refers to the warning of calling dump() without CORE::, yes.
0
xsawyerx
1/14/2017 5:07:01 PM
--Sig_/bcnC5BZV/1dqdHEIVZkcbiE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, 14 Jan 2017 17:36:52 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

> On 01/11/2017 01:15 PM, Dave Mitchell wrote:
> > On Tue, Jan 10, 2017 at 12:05:39PM +0100, =C3=86var Arnfj=C3=B6r=C3=B0 =
Bjarmason wrote: =20
>  [...] =20
> >> Shouldn't we be consistent here and either make all previously magical
> >> variables listed in perlvar either not special at all (as seems to be
> >> the plan with $* & $#), or reserve them forever by making their use
> >> fatal as is the plan with $[?
> >>
> >> My bias would be to just make them all fatal, despite all these old
> >> deprecation warnings someone will dig up an old script / blogpost /
> >> Matt's Script Archive entry and try to execute it, I think it would be
> >> more helpful to just die in those cases instead of introducing subtle
> >> behavior differences. =20
> > +1 =20
>=20
> I reckon this was an oversight. I'm also in favor of making them all fata=
l.
>=20
> Any objections?

Not from me. sounds logic

--=20
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.25   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

--Sig_/bcnC5BZV/1dqdHEIVZkcbiE
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJYe1G0AAoJEAOhR6E+XcCY1FkIAJ78dYTL4thN5TwY6YpRXZQJ
IgGBsOTyfoDPp+4yDhV8S2vjYsW9mbEM4nILfYhwHun2MTL2CUIB3KhQmFSO4sDy
TEP7guPagdUUDgWE9cZHGkUiBurfc6x09D45pjoGze1E7ipWGsAIxVHWyA1xkbdK
AeiuozWhsMlrZjHnDp4qzP3wLLBiOGgqB6JuSAKxfb16/ukDw1zDDmlTz9dLff79
YnfKeDVXdT9TuGvHWf3IIRgxmNLvxSGgs5w+wE2zRWban4aqDWWJT81O8oZ9eyq7
1pAXXVTepchdT8dmw82DtPaG8Mje0z61Y8XAguQ5cc7fEFeZgL9GqqdlS0HRC4U=
=BgJd
-----END PGP SIGNATURE-----

--Sig_/bcnC5BZV/1dqdHEIVZkcbiE--
0
h
1/15/2017 10:40:43 AM

On 01/14/2017 05:36 PM, Sawyer X wrote:
>
> On 01/11/2017 01:15 PM, Dave Mitchell wrote:
>> On Tue, Jan 10, 2017 at 12:05:39PM +0100, �var Arnfj�r� Bjarmason wrote:
>>>> * $* is no longer supported: Functionality removed in 5.10.0, removing
>>>> the warning.
>>>>
>>>> * $# is no longer supported: Functionality removed in 5.10.0, removing
>>>> the warning.
>>> Shouldn't we be consistent here and either make all previously magical
>>> variables listed in perlvar either not special at all (as seems to be
>>> the plan with $* & $#), or reserve them forever by making their use
>>> fatal as is the plan with $[?
>>>
>>> My bias would be to just make them all fatal, despite all these old
>>> deprecation warnings someone will dig up an old script / blogpost /
>>> Matt's Script Archive entry and try to execute it, I think it would be
>>> more helpful to just die in those cases instead of introducing subtle
>>> behavior differences.
>> +1
> I reckon this was an oversight. I'm also in favor of making them all fatal.

Abigail clued me in on the oversight.

$* and $# have lost their "magic" characteristic back in 5.10. That is
why they fell off the radar and $[ was considered for a proper
deprecation and fatalization cycle.

On 5.16 $[ was changed so if you call "use v5.16" or "no feature
'array_base'" $[ simply has no effect, although you can still set it to
0. This means that it, unless you apply the previously mentioned pragma
calls, this variable still has usage, and this is why it *must* go
through a deprecation cycle and why we noted that. I think there's
probably little value in calling fatal on $* and $# since they have no
usage (in any form) from 5.10. However, for cleanliness sense, and to
allow us to communicate for certain that we don't accept it (and allow
us to possibly make a new use of them in the future), we might as well
fatalize them as well. I think a deprecation cycle of warning before
fatalizing would be better, in case anyone has them still in older
scripts that somehow passed an upgrade to 5.10 and above without
breaking. (I'm honestly not sure how likely that is, but we're not in a
rush anyway with them.)
0
xsawyerx
1/15/2017 10:50:48 AM
--94eb2c18e6542f950d0546375b5f
Content-Type: text/plain; charset=UTF-8

On Sun, Jan 15, 2017 at 11:50 AM, Sawyer X <xsawyerx@gmail.com> wrote:

> Abigail clued me in on the oversight.
>
> $* and $# have lost their "magic" characteristic back in 5.10. That is
> why they fell off the radar and $[ was considered for a proper
> deprecation and fatalization cycle.
>
> On 5.16 $[ was changed so if you call "use v5.16" or "no feature
> 'array_base'" $[ simply has no effect, although you can still set it to
> 0. This means that it, unless you apply the previously mentioned pragma
> calls, this variable still has usage, and this is why it *must* go
> through a deprecation cycle and why we noted that. I think there's
> probably little value in calling fatal on $* and $# since they have no
> usage (in any form) from 5.10. However, for cleanliness sense, and to
> allow us to communicate for certain that we don't accept it (and allow
> us to possibly make a new use of them in the future), we might as well
> fatalize them as well. I think a deprecation cycle of warning before
> fatalizing would be better, in case anyone has them still in older
> scripts that somehow passed an upgrade to 5.10 and above without
> breaking. (I'm honestly not sure how likely that is, but we're not in a
> rush anyway with them.)
>

I don't think there's any value anymore in fatalizing $# and $* at this
point. Besides, fatalizing them breaks my favorite perl/postscript script
ever [1] ;-) (by Book of course).

Leon

1: http://perl.plover.com/obfuscated/bestever.pl

--94eb2c18e6542f950d0546375b5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jan 15, 2017 at 11:50 AM, Sawyer X <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:xsawyerx@gmail.com" target=3D"_blank">xsawyerx@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D=
"gmail-"></span>Abigail clued me in on the oversight.<br>
<br>
$* and $# have lost their &quot;magic&quot; characteristic back in 5.10. Th=
at is<br>
why they fell off the radar and $[ was considered for a proper<br>
deprecation and fatalization cycle.<br>
<br>
On 5.16 $[ was changed so if you call &quot;use v5.16&quot; or &quot;no fea=
ture<br>
&#39;array_base&#39;&quot; $[ simply has no effect, although you can still =
set it to<br>
0. This means that it, unless you apply the previously mentioned pragma<br>
calls, this variable still has usage, and this is why it *must* go<br>
through a deprecation cycle and why we noted that. I think there&#39;s<br>
probably little value in calling fatal on $* and $# since they have no<br>
usage (in any form) from 5.10. However, for cleanliness sense, and to<br>
allow us to communicate for certain that we don&#39;t accept it (and allow<=
br>
us to possibly make a new use of them in the future), we might as well<br>
fatalize them as well. I think a deprecation cycle of warning before<br>
fatalizing would be better, in case anyone has them still in older<br>
scripts that somehow passed an upgrade to 5.10 and above without<br>
breaking. (I&#39;m honestly not sure how likely that is, but we&#39;re not =
in a<br>
rush anyway with them.)<br>
</blockquote></div><br><div class=3D"gmail_extra">I don&#39;t=20
think there&#39;s any value anymore in fatalizing $# and $* at this point.=
=20
Besides, fatalizing them breaks my favorite perl/postscript script ever=20
[1] ;-) (by Book of course).<br><br></div><div class=3D"gmail_extra">Leon<b=
r></div><br>1: <a href=3D"http://perl.plover.com/obfuscated/bestever.pl" ta=
rget=3D"_blank">http://perl.plover.com/<wbr>obfuscated/bestever.pl</a><br><=
/div></div>

--94eb2c18e6542f950d0546375b5f--
0
fawaka
1/16/2017 2:53:49 PM
On Mon, Jan 16, 2017 at 03:53:49PM +0100, Leon Timmermans wrote:
> On Sun, Jan 15, 2017 at 11:50 AM, Sawyer X <xsawyerx@gmail.com> wrote:
> 
> > Abigail clued me in on the oversight.
> >
> > $* and $# have lost their "magic" characteristic back in 5.10. That is
> > why they fell off the radar and $[ was considered for a proper
> > deprecation and fatalization cycle.
> >
> > On 5.16 $[ was changed so if you call "use v5.16" or "no feature
> > 'array_base'" $[ simply has no effect, although you can still set it to
> > 0. This means that it, unless you apply the previously mentioned pragma
> > calls, this variable still has usage, and this is why it *must* go
> > through a deprecation cycle and why we noted that. I think there's
> > probably little value in calling fatal on $* and $# since they have no
> > usage (in any form) from 5.10. However, for cleanliness sense, and to
> > allow us to communicate for certain that we don't accept it (and allow
> > us to possibly make a new use of them in the future), we might as well
> > fatalize them as well. I think a deprecation cycle of warning before
> > fatalizing would be better, in case anyone has them still in older
> > scripts that somehow passed an upgrade to 5.10 and above without
> > breaking. (I'm honestly not sure how likely that is, but we're not in a
> > rush anyway with them.)
> >
> 
> I don't think there's any value anymore in fatalizing $# and $* at this
> point. Besides, fatalizing them breaks my favorite perl/postscript script
> ever [1] ;-) (by Book of course).



It frees up two punctuation variables for future use.



Abigail
0
abigail
1/16/2017 3:07:32 PM
--94eb2c19204cdbdd7a054637f737
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 16, 2017 at 4:07 PM, Abigail <abigail@abigail.be> wrote:

> It frees up two punctuation variables for future use.
>

Their functionality has been removed a decade ago, as far as I'm concerned
they're already free (but I also hope we're never going to use them again).

Leon

--94eb2c19204cdbdd7a054637f737
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 16, 2017 at 4:07 PM, Abigail <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:abigail@abigail.be" target=3D"_blank">abigail@abigail.be</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D""></span>It frees up=
 two punctuation variables for future use.<br>
</blockquote><div><br></div><div>Their functionality has been removed a dec=
ade ago, as far as I&#39;m concerned they&#39;re already free (but I also h=
ope we&#39;re never going to use them again).<br><br></div><div>Leon<br></d=
iv></div><br></div></div>

--94eb2c19204cdbdd7a054637f737--
0
fawaka
1/16/2017 3:37:38 PM
On Mon, Jan 16, 2017 at 04:37:38PM +0100, Leon Timmermans wrote:
> On Mon, Jan 16, 2017 at 4:07 PM, Abigail <abigail@abigail.be> wrote:
> 
> > It frees up two punctuation variables for future use.
> >
> 
> Their functionality has been removed a decade ago, as far as I'm concerned
> they're already free (but I also hope we're never going to use them again).
> 


They don't have a special meaning, but they're as un-free to use
for future use as $i. Since they have no special meaning, they 
can act as normal [1] variables -- and just taking them to be
used for anything specific would require deprecation.

Might as well do it now.



[1]  Assuming that punctuation variables can ever be "normal".



Abigail
0
abigail
1/16/2017 4:23:45 PM
On Sun, Jan 08, 2017 at 07:22:55PM +0100, Sawyer X wrote:
> Hi everyone,
> 
> 
> During the core hackathon in Amsterdam, we had a large discussion[1] on
> deprecations. This resulted in two decisions:
> 
> * From now on, deprecations must include a version in which the
> deprecation will take effect. This is to avoid the current situation in
> which there are numerous deprecations still in the code, some over 10,
> 15, or 20 years old.
> 
> * Every current existing deprecation must either be pinned with an
> effective version or be undeprecated.
> 
> 
> During the discussion we went over all existing deprecations and made a
> collective decision on both, while trying to remain both practical and
> lenient where appropriate. I present the decisions we made. Abigail is
> currently working on putting these all into work prior to 5.25.9. A big
> thank you to everyone who attended this grueling Hunger Games of
> deprecated features and syntaxes, and to Abigail for the work on leading
> this and making it a reality. :)


I merged in my branch with all the updated deprecation messages
as per the list below, with the following exceptions:

   *  Use of $* and $# will be fatal by 5.30 (instead of just removing
      the current warning).

   *  No change yet for what to do with $[. We want to have further
      discussing on whether we perhaps should undeprecate modifying $[.

   *  Nothing done for using "goto" to jump into a construct, as there's
      some opposition of removing this.


For the latter two points, we want to decide no later than 5.28 what
to do with those features (so we can discuss this for the next 16 months).


I've also created a document perldeprecation listing all items which are
deprecated, grouped by Perl version in which the item is scheduled to
disappear. For most items, this is mostly a copy of what's in perldiag,
but once a feature is removed, it will disappear from perldiag, but 
the entry can stay in perldiag for future reference. Over time, I'd like
to do some archeology, and document features which have been removed
in the past.



Abigail

> 
> 
> The list:
> 
> * Attribute "locked" is deprecated: Deprecated in 5.12.0, delete in 5.28.
> 
> * Attribute "unique" is deprecated: Deprecated in 5.12.0, delete in 5.28.
> 
> * Calling POSIX::%s() is deprecated: Removing from perldiag.
> 
> * Constants from lexical variables potentially modified elsewhere are
> deprecated: Delete in 5.32.
> 
> * Deprecated use of my() in false conditional: Deprecated in 5.10.0,
> remove in 5.30.0.
> 
> * ${^ENCODING} is no longer supported: Partially deprecated in 5.22.0,
> fully deprecated in 5.25.3, fatal in 5.28.
> 
> * $* is no longer supported: Functionality removed in 5.10.0, removing
> the warning.
> 
> * $# is no longer supported: Functionality removed in 5.10.0, removing
> the warning.
> 
> * Opening dirhandle %s also as a file: Deprecated in 5.10.0, fatal in 5.28.
> 
> * Opening filehandle %s also as a directory: Deprecated in 5.10.0, fatal
> in 5.28.
> 
> * Passing malformed UTF-8 to "%s" is deprecated: Deprecated since
> 5.18.0, fatal in 5.25.9.
> 
> * Setting ${^ENCODING} is deprecated: Deprecated in 5.22.0. Remove text.
> 
> * Setting $/ to a reference to %s as a form of slurp is deprecated,
> treating as undef: Deprecated in 5.20.0, fatal in 5.28.
> 
> * Unescaped left brace in regex is deprecated here, passed through in
> regex; marked by S<<-- HERE> in m/%s/: Deprecated in 5.25.2, fatal in 5.30.
> 
> * Unknown charname '' is deprecated: Deprecated since 5.24.0, remove in
> 5.28.0.
> 
> * Use of assignment to $[ is deprecated: Deprecated in 5.12.0; list
> context deprecated in 5.14.0, fatal in 5.28 (unless you use arybase)
> 
> * Use of bare << to mean <<"" is deprecated: Deprecated in 5.000, remove
> in 5.28.0.
> 
> * Use of code point 0x%s is deprecated; the permissible max is 0x%s:
> Deprecated since 5.24.0, remove in 5.28.
> 
> * Use of comma-less variable list is deprecated: Remove in 5.28.
> 
> * Use of *glob{FILEHANDLE} is deprecated: Deprecated in 5.8,
> undeprecated in 5.24.0, remove from perldiag.
> 
> * Use of "goto" to jump into a construct is deprecated: Deprecated in
> 5.12.0, remove in 5.28.0.
> 
> * Use of inherited AUTOLOAD for non-method %s() is deprecated:
> Deprecated since 5.004, remove in 5.28.
> 
> * Use of %s is deprecated: Remove text.
> 
> * Use of %s on a handle without * is deprecated: Remove text.
> 
> * Use of strings with code points over 0xFF as arguments to %s operator
> is deprecated: Deprecated in 5.24.0, removed in 5.28.0.
> 
> * dump() better written as CORE::dump(): Make it a deprecation warning;
> dump no longer available in 5.30.
> 
> * File::Glob::glob(): Deprecated in 5.8, add deprecation warning in
> 5.25.9, remove in 5.30.
> 
> * "L<section>": Deprecated in 5.12.0.
> 
> * "%s" is more clearly written simply as "%s": Deprecated in 5.14.0,
> removed in 5.28.
> 
> * Don't read the Unicode data base files in F<lib/unicore>: Deprecated
> in 5.16.0, no action for now.
> 
> * "--libpods" in Pod::Html: Warn since 5.18.0, remove in 5.26.
> 
> * sysread(), syswrite(), recv() and send() are deprecated on :utf8
> handles: Deprecated in 5.24.0, remove in 5.30.
> 
> * $! vs $^E for Winsock functions: Deprecated in 5.24.0, put in
> perlport, no action for now.
> 
> * Utils: c2ph, pstruct: Deprecated in favor of h2xs, gone in 5.26.0.
> 
> * %SIG: Undeprecate.
> 
> * B::OP::terse: Remove in 5.28.0.
> 
> 
> [1] This included Abigail, Yves Orton, Dave Mitchell, Karl Williamson,
> Nicholas Clark, Ilmari, Leon Timmermans, Aaron Crane, Matthew Horsfall,
> Lukas Mai, Tux, Nicolas (Atoomic) Rochelemagne, Todd Rinaldo, John
> Lightsey, Nick Koston, Stevan Little, and myself. (This is out of memory
> and a bit of checking. I apologize if I forgot anyone.)
0
abigail
1/16/2017 9:25:22 PM
On Mon, Jan 16, 2017 at 10:25:22PM +0100, Abigail wrote:
> I merged in my branch with all the updated deprecation messages
> as per the list below.

Thanks.

A few tests are now producing noise on stderr. Could these be quietened
one way or another:


dump() better written as CORE::dump(). dump() will no longer be available in Perl 5.30 at (eval 30) line 1.
"\c#" is more clearly written simply as "c". This will be a fatal error in Perl 5.28 at re/regex_sets.t line 168.
"\c#" is more clearly written simply as "c". This will be a fatal error in Perl 5.28 at re/regex_sets.t line 168.
dump() better written as CORE::dump(). dump() will no longer be available in Perl 5.30 at (eval 302) line 1.
File::Glob::glob() will disappear in perl 5.30. Use File::Glob::bsd_glob() instead. at ../ext/File-Glob/t/basic.t line 47.


-- 
Standards (n). Battle insignia or tribal totems.
0
davem
1/17/2017 3:48:19 PM
On Tue, Jan 17, 2017 at 03:48:19PM +0000, Dave Mitchell wrote:
> On Mon, Jan 16, 2017 at 10:25:22PM +0100, Abigail wrote:
> > I merged in my branch with all the updated deprecation messages
> > as per the list below.
> 
> Thanks.
> 
> A few tests are now producing noise on stderr. Could these be quietened
> one way or another:
> 
> 
> dump() better written as CORE::dump(). dump() will no longer be available in Perl 5.30 at (eval 30) line 1.
> "\c#" is more clearly written simply as "c". This will be a fatal error in Perl 5.28 at re/regex_sets.t line 168.
> "\c#" is more clearly written simply as "c". This will be a fatal error in Perl 5.28 at re/regex_sets.t line 168.
> dump() better written as CORE::dump(). dump() will no longer be available in Perl 5.30 at (eval 302) line 1.
> File::Glob::glob() will disappear in perl 5.30. Use File::Glob::bsd_glob() instead. at ../ext/File-Glob/t/basic.t line 47.
> 



Thanks for spotting these. They should now be fixed.



Abigail
0
abigail
1/17/2017 10:10:16 PM

On 01/16/2017 10:25 PM, Abigail wrote:
> On Sun, Jan 08, 2017 at 07:22:55PM +0100, Sawyer X wrote:
>> Hi everyone,
>>
>>
>> During the core hackathon in Amsterdam, we had a large discussion[1] on
>> deprecations. This resulted in two decisions:
>>
>> * From now on, deprecations must include a version in which the
>> deprecation will take effect. This is to avoid the current situation in
>> which there are numerous deprecations still in the code, some over 10,
>> 15, or 20 years old.
>>
>> * Every current existing deprecation must either be pinned with an
>> effective version or be undeprecated.
>>
>>
>> During the discussion we went over all existing deprecations and made a
>> collective decision on both, while trying to remain both practical and
>> lenient where appropriate. I present the decisions we made. Abigail is
>> currently working on putting these all into work prior to 5.25.9. A big
>> thank you to everyone who attended this grueling Hunger Games of
>> deprecated features and syntaxes, and to Abigail for the work on leading
>> this and making it a reality. :)
>
> I merged in my branch with all the updated deprecation messages
> as per the list below, with the following exceptions:

Thank you, Abigail! :)
0
xsawyerx
1/20/2017 9:16:33 PM
Reply: