Porters,
I "use experimental" pretty often. Sometimes it's to use experiments that I like, where I feel up to taking on the risk. Other times, though, it's to use experiments that, well, aren't really experiments anymore. For example, most modules in Dist-Zilla begin with this boiler plate:
use v5.20.0;
use warnings;
use utf8;
no feature 'switch';
use experimental qw(postderef postderef_qq); # This experiment gets mainlined.
That last line's comment is trying to say, "Don't panic! I'm using something that says it's an experiment, because it was one in v5.20, but it never changed between then and when it got turned on for everybody."
What I want is a way to say "I would like to enable a feature which was experimental once, but is safe to enable in some range of versions of perl because it eventually landed without changes."
One option would be a new pragma:
use futuristic qw(postderef postderef_qq);
On v5.18 and earlier, this would die. On v5.20 and later, it would act like "use experimental". This would make it easy to ship code to the CPAN that uses eventually-accepted experiments even on versions where they were still experimental, but without the worrying "use experimental." Also, it could guard against using experiments before they became stable. For example, the behavior of signatures changed in a few ways already. The behavior of switch changed between 5.10 and 5.10.1. Lexical subroutines didn't change behavior, but were extremely crashy in their early iteration.
Imagine a feature with the following lifecycle:
v5.40 - feature foozles is added, and is experimental
v5.41 - feature foozles has its design changed
v5.42 - feature foozles is present with new design, and is still experimental
v5.43 - feature foozles does not change during this series
v5.44 - feature foozles ceases to be experimental
After the release of v5.44, if a used wrote "use futuristic 'foozles'"…
* it would die on v5.40
* it would enable the feature and disable the warnings on v5.42
* it would enable the feature on v5.42
It would also be possible to, rather than add "futuristic.pm", make feature.pm dual life. This would require some rejiggering of the feature.pm code, but would reduce the number of names to learn.
--
rjbs
I "use experimental" pretty often. Sometimes it's to use experiments that I like, where I feel up to taking on the risk. Other times, though, it's to use experiments that, well, aren't really experiments anymore. For example, most modules in Dist-Zilla begin with this boiler plate:
use v5.20.0;
use warnings;
use utf8;
no feature 'switch';
use experimental qw(postderef postderef_qq); # This experiment gets mainlined.
That last line's comment is trying to say, "Don't panic! I'm using something that says it's an experiment, because it was one in v5.20, but it never changed between then and when it got turned on for everybody."
What I want is a way to say "I would like to enable a feature which was experimental once, but is safe to enable in some range of versions of perl because it eventually landed without changes."
One option would be a new pragma:
use futuristic qw(postderef postderef_qq);
On v5.18 and earlier, this would die. On v5.20 and later, it would act like "use experimental". This would make it easy to ship code to the CPAN that uses eventually-accepted experiments even on versions where they were still experimental, but without the worrying "use experimental." Also, it could guard against using experiments before they became stable. For example, the behavior of signatures changed in a few ways already. The behavior of switch changed between 5.10 and 5.10.1. Lexical subroutines didn't change behavior, but were extremely crashy in their early iteration.
Imagine a feature with the following lifecycle:
v5.40 - feature foozles is added, and is experimental
v5.41 - feature foozles has its design changed
v5.42 - feature foozles is present with new design, and is still experimental
v5.43 - feature foozles does not change during this series
v5.44 - feature foozles ceases to be experimental
After the release of v5.44, if a used wrote "use futuristic 'foozles'"…
* it would die on v5.40
* it would enable the feature and disable the warnings on v5.42
* it would enable the feature on v5.42
It would also be possible to, rather than add "futuristic.pm", make feature.pm dual life. This would require some rejiggering of the feature.pm code, but would reduce the number of names to learn.
--
rjbs