Front page | perl.perl5.porters |
Postings from January 2017
Re: Deprecation plans
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
January 14, 2017 17:07
Subject:
Re: Deprecation plans
Message ID:
096e5596-a40c-0615-c5af-0e3718e2c7b0@gmail.com
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.
Thread Previous
|
Thread Next