Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
From: Rocco Caputo
July 5, 2016 00:35
Re: Indented here docs?
Message ID: 0F63CAB4-F9E1-40CF-BB92-9F6609F5C89A@pobox.com
> On Jul 4, 2016, at 17:25, Sawyer X <email@example.com> wrote:
> On 07/03/2016 10:31 PM, Dagfinn Ilmari Mannsåker wrote:
>> Father Chrysostomos <firstname.lastname@example.org> writes:
>>> Paul Johnson wrote:
>>>> On Sun, Jul 03, 2016 at 03:28:56PM -0400, Matthew Horsfall (alh) wrote:
>>>>> Aside from the above, do we have a decision/consensus on if we need a
>>>>> deprecation cycle for the existing behaviour of <<-EOF / <<-"EOF" etc?
>>>>> (which, as far as I can tell, is to throw a warning and then
>>>>> eventually fail compilation? Or are there some cases where this is
>>>>> legal somehow?
>>>>> Also, is this going experimental for 5.26?
>>>> I suppose that one option is to have a deprecation cycle in 5.26, and
>>>> also add this as experimental option which would silence those
>>>> deprecation messages. Then we might want to relax our rules about two
>>>> stable releases and remove the experimental status in 5.28.
>>> The existing behaviour of <<- is already deprecated. I think we can
>>> go ahead and change it.
>> Just a data point: it's been deprecated since 5.002, i.e. for over 20
>> years. As far as I can tell it's the second-oldest deprecation still in
>> place in toke.c, after comma-less variable lists in formats, which was
>> deprecated in 5.000.
> This point is very convincing. I'm not against adding this as 5.26
> experimental while deprecating fully <<-, as Paul suggests.
> If all goes well, and we don't experience problems, I'm in favor of
> considering relaxing the rules for this specific one for 5.28. No
> promises, though.
> Sounds reasonable?
> Does anyone object?
I object. People who aren't following P5P will see this as an ad hoc exception made at a risk to users because Perl's developers wanted the feature sooner. Anyone bitten by the change will not recognize the global risk as being small. It sets a bad precedent for inconsistent development behavior. It undermines P5P's and Perl's reliability.
All my objections go away if this new rule is codified before it's followed: Anything deprecated 20 years or more can be removed or altered without further notice. It still sets a precedent, but the scope is much narrower. It's not as capricious.
For maximum fairness, policy changes should be published before they're followed, but the skin in the game I'm trying to protect is y'all's, not my own.
Rocco Caputo <email@example.com>