On Sat, Dec 30, 2017 at 7:09 PM, Ãvar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > > > I'm pretty sure we will never retroactively mark feature as > > experimental ever again. > > What'll that mean? That per perlpolicy.pod we'll mark it directly as > deprecated? And thus give users even fewer releases to notice that they > shouldn't be using them? > > Let's say, as an extreme example, that I'd push a patch to perl.git to > change "print" to "outputstuff": > > x) If I were to mark "print" as deprecated I'd have to wait from 5.28 > to 5.32. > > y) You're saying (If I'm getting this right) "we'll never retroactively > mark af feature as experimental again", what does that mean? I view > that as an *extra* layer on top of "depecated", i.e. we'd add > "outputstuff" instead of "print" in 5.28, then warn, and it would be > an opt-in feature (via warning) until 5.32. > > Only in 5.32 would we deprecate "print" and say "this is going > away", and finally remove it in 5.36. > > How's that better for our users? You're just saying that they should be > given less notice of invasive changes. > Experimental status was not designed to be used this way. It's intended that new features will be added under that umbrella so that users are aware it could be changed without a deprecation period. That it was retroactively applied for smartmatch and lexical $_ only occurred because those features were introduced before Perl had an experimental features policy. -DanThread Previous | Thread Next