develooper Front page | perl.perl5.porters | Postings from June 2017

Re: Deprecation of ${^ENCODING}

Thread Previous | Thread Next
From:
Karl Williamson
Date:
June 7, 2017 18:22
Subject:
Re: Deprecation of ${^ENCODING}
Message ID:
05278d6e-5d31-8fe7-d490-2b38756f476b@khwilliamson.com
On 06/07/2017 10:27 AM, Abigail wrote:
> 
> We previously decided to outlaw the use of ${^ENCODING} by 5.28,
> and we have been issueing a warning:
> 
>      $ perl5.26.0 -wE '${^ENCODING} = 0'
>      ${^ENCODING} is no longer supported. Its use will be fatal in Perl 5.28 at -e line 1.
> 
> 
> However, it turns out we only gave out this warnings if we try
> to set ${^ENCODING} to a defined value. None of the following
> lines warn:
> 
>      $ perl5.26.0 -wE '${^ENCODING} = undef'
>      $ perl5.26.0 -wE 'undef ${^ENCODING}'
>      $ perl5.26.0 -wE 'local ${^ENCODING}'
> 
> 
> Which raises the question, what should we do? Should we warn (with
> a message it will be gone in 5.30) when we try to assign an undefined
> value to ${^ENCODING}, and die when trying to assign a defined value? Or
> bump the deprecation message to 5.30, and now warn even when assigning
> an undefined value? If we just make it a fatal error we may see a lot
> of code failures (there are a number of test files in cpan/Encode which
> will fail -- including at least one test file which just hangs).
> 
> 
> 
> Abigail
> 

I earlier started working on fatalizing this, and decided it was best 
just to allow undeffing the variable without any message and no 
expectation of changing.  If we did want to excise all mentions of it 
for some reason, it would have to be deprecated for a while.  I 
personally don't see any need to force CPAN modules to make any changes 
in this regard.  It's just extra work, and I don't see any real payoff.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About