develooper Front page | perl.perl5.porters | Postings from December 2017

Re: We need a language design process.

Thread Previous | Thread Next
From:
Dan Book
Date:
December 31, 2017 00:15
Subject:
Re: We need a language design process.
Message ID:
CABMkAVVysN7-MOd-msyE9YsaXtm_tiM1zntqD5rtVXKkLoxjSA@mail.gmail.com
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.

-Dan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About