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

Re: We need a language design process.

Thread Previous | Thread Next
Ævar Arnfjörð Bjarmason
December 31, 2017 00:33
Re: We need a language design process.
Message ID:

On Sun, Dec 31 2017, Dan Book jotted:

> On Sat, Dec 30, 2017 at 7:09 PM, Ævar Arnfjörð Bjarmason <>
> 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.

So we shouldn't grandfather any sort of features that used to be
non-experimental as "deprecated"?

Which would mean that if we all agree in principle that Zefram's patches
are fine that we'd have to declare the current given/when semantics as
deprecated in 5.28, and then remove them in 5.32 in 2020?

So, in general, if something was an established feature of perl and
we've later made it "experimental" that should mean absolutely nothing
at all, instead we should just say "oh it's been warning as
'experimental' for a while, but nevermind that, wait until we mark it as
deprecated, then we'll really mean it".

I think that's crazy. If I upgrade perl every year and I have a feature
yelling at me for 2 years, and then it's changed, that should count for
less than if I have a feature yelling at me for 2 years and then it's

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About