develooper Front page | perl.perl5.porters | Postings from June 2020

Re: Announcing Perl 7

Thread Previous | Thread Next
Charles McGarvey
June 27, 2020 17:55
Re: Announcing Perl 7
Message ID:
On 6/27/20 11:00 AM, Paul "LeoNerd" Evans wrote:
> On Sat, 27 Jun 2020 12:46:53 -0400
> Dan Book <> wrote:
>> I disagree, with both the premise and conclusion. It is in use, maybe
>> not always explicitly, but via modules doing the exact same thing.
>> Mojolicious currently provides the equivalent of "use v5.16" to all
>> of its own and user code, plus some other useful things like "use
>> warnings" and "use utf8" which we should really consider adding to
>> the "use VERSION" functionality. Any time which I could use "use
>> VERSION" and did not, it was only because I end up having to add an
>> explicit "use warnings" anyway.
> I'm with Dan on this one.
> I would probably use "use VERSION" a lot more often, if it actually did
> more things. At the moment it barely has any effect besides declaring
> the required version. If "use VERSION" actually did turn on warnings
> and generally fiddled around with featuresets a lot more like we're
> proposing - and a use v7 would - then I would use it a lot more.

"use VERSION" does implicitly load feature bundles. There is no bundle that
includes strict or warnings, but there's probably no reason why the ":7.00"
bundle couldn't do that to reduce some boilerplate.

> I don't think the argument that "nobody uses use VERSION now" to be all
> that appealing. Nobody uses it now because it's largely useless. Make
> it useful and people will use it.

The disuse of "use VERSION" has been asserted a couple times, but I actually
thought it was fairly common. Maybe I'm wrong. But I use it and so does my
$company. It's nice because of the aforementioned implicit feature bundle
loading and (as you say) to act as an annotation for static code analyzers,
syntax highlighters, and humans alike.

>> To summarize my overall point: I do not think that changing the
>> default enabled features sufficiently solves the stated problems, to
>> justify the amount of effort it will take to overcome the breakage it
>> will introduce, when compared with an improved "use v7" which does
>> not introduce any breakage and solves these problems as well.
> +1
> I especially agree with the part about authors of CPAN modules trying
> to be polite to older versions - I have quite a few of those myself.
> Right none almost none of them will be capable of being 7-friendly if 7
> just presumes its semantics without my say-so. If 7 required "use v7"
> to actually turn on 7-syntax then things like List::UtilsBy will
> continue to run without the horrible hack that is currently my attempt
> to monkeypatch a :prototype() into older Perls. [see other thread]


I'm still forming my opinions of the perl7 plan and still have questions that
need answers, but I will say for now that if I take a step back and consider
what I would want to see in a language that I'm pretending to have no
emotional attachment to, I think I'd have to say "use v" makes more sense than
"use compat::perlV". But I'll keep an open mind.

Maybe it's because I already use "use v" and so am acclimated to this idea,
but if Perl 7 was released under the current plan and I wanted to write
software targeting it, I would be tempted to include as boilerplate "use
compat::perl7" even if Perl 8 wasn't available yet, because I know someday
Perl 8 (or later) will be released with altered syntax and I don't want to
have to come back to code that is already working just to add a
"compat::perl7" just so that it continues to work in newer perls (at least
until any deprecated syntax I'm using gets removed, which is fine).

Charles McGarvey

Just another p5p lurker

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