Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
Thread Previous
|
Thread Next
From:
Zefram
Date:
July 11, 2016 01:36
Subject:
Re: Indented here docs?
Message ID:
20160711013549.GL1170@fysh.org
Aristotle Pagaltzis wrote:
>*If* we want to do something similar again. But we have no such plans at
>this time.
If we wait until we've actually run out of non-clashing syntax, that would
be a much worse impediment. It might lead us to cut corners, such as by
reassigning legal syntax to a new meaning within a single major version.
>That is the exact opposite of the current dictum to not break backcompat
>until and unless it impedes actual changes.
It did impede this change: we did not have a free choice of reasonable
syntactic options. We've used just about the only one available.
Given the precedents in other languages for "<<-", there was a good
case for using that, but we can't. Since we're not doing exactly the
same thing as either of the precedents, there was also a good case
for using a character that's similar but deliberately not the same.
We've roughly done that, but "<<~" is on the edge of that "similar" space.
"<<+" would have been a better choice.
> Since long-standing deprecations are bad for
>the language, it should be done away with.
You can't have it both ways. A policy requiring some degree of
active impediment to new development for removal inherently means
that deprecations will tend to last a long time. If you want to avoid
long-duration deprecations, by all means agitate for a change to the rule,
to allow (or require) deprecated features to be removed two major versions
after deprecation, even if they're not yet actually causing trouble.
I think your argument suffers from failing to distinguish between classes
of clash between deprecation and new development. There are some cases,
such as $[, where support for a deprecated feature implies some internals
that are troublesome, and so impede later features that don't necessarily
have any user-obvious link. In those cases we can delete a deprecated
feature and reap the benefit of doing so in the same version. So in
those cases it is reasonable to look for such imminent benefits as the
precondition for removal, as you advocate.
Deprecating the use of some syntactic space, clashing with proposed
reuses of that syntactic space, has a different character. In this kind
of case, removing the deprecated use and then reusing the syntax in the
same version would cause an obvious compatibility problem. To avoid
silently changing the meaning of any program, we'd really like to perform
a more staged transition, with the syntax lying fallow for a couple of
major versions. We don't always do that -- it's a tradeoff -- but we'd
certainly like to do it. If we wait for a specific reuse to be decided
upon, then the full process would take three years to introduce the new
feature. Given the downsides of that, it's reasonable to apply a weaker
standard for clashes to trigger removal: a semi-specific anticipation of
syntax reuse, or as in the present case an averted clash demonstrating
that the syntax would be profitable to reuse.
I interpret our policy on removing deprecated features to allow this
kind of nuanced decision about the required justification. The policy
is not a set of absolutely strict criteria; reasonableness in applying
the policy is required throughout.
-zefram
Thread Previous
|
Thread Next