Front page | perl.perl5.porters |
Postings from January 2012
On 01/30/2012 10:18 AM, Karl Williamson wrote:
> On 01/30/2012 01:06 AM, hv@crypt.org wrote:
>> David Golden<xdaveg@gmail.com> wrote:
>> :I expect that 99.9%+ of Perl users do not build dev releases (much
>> :less test code on them), as much as we encourage them to. Thus, I
>> :don't expect anyone to react to a deprecation warning until the stable
>> :release in which deprecation warnings start. (Thankfully, we have
>> :Andreas who regularly smokes blead because that's most of the "live
>> :code" smoking we get.)
>> :
>> :So while I don't like "risky" code late in the dev cycle (by which I
>> :mean things that are complex and might have surprising bugs revealed
>> :in testing), I don't see any reason why deprecations can't be
>> :introduced right up to the code freeze, since the only point it really
>> :affects most users is when the stable release is done.
>>
>> I consider this deprecation risky: it may break things by being
>> misimplemented, or it may break things by introducing new warnings deep
>> in code that doesn't expect it. Further, I consider there is a non-zero
>> probability that once we try it we may find that the practice we wish
>> to deprecate is so widespread that we reconsider our approach.
>>
>> In particular, this isn't some practice that was previously dubious or
>> "always broken" - as far as I know, the norm and received wisdom has
>> always been "don't escape what doesn't require it".
>>
>> Attempting this at the start of a cycle would give us the space we need
>> to discover whether it's a really bad idea.
>>
>> Hugo
>>
>
> It's not clear to me if you are referring to just the more general
> proposal to deprecate all unescaped left braces; or the more restricted
> one to deprecate those in a backslash-alpha-brace sequence.
>
> The former has already been marked as contentious, so will not go into
> 5.16. If the latter, then it too can not be implemented in 5.16.
>
BTW, one advantage of doing either of these is that people have
complained, and their may be tickets open on (don't have time just now
to check) that if they make a typo in a {quantifier}, there's no
message. Now there would be, and we could close any of those tickets
Thread Previous
|
Thread Next