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.Thread Previous | Thread Next