develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Pre-RFC: a `module` keyword

Thread Previous | Thread Next
From:
Tomasz Konojacki
Date:
January 24, 2022 20:38
Subject:
Re: Pre-RFC: a `module` keyword
Message ID:
20220124213842.303A.5C4F47F8@xenu.pl
On Mon, 24 Jan 2022 19:20:41 +0000 (UTC)
Ovid via perl5-porters <perl5-porters@perl.org> wrote:

> * Strict, warnings, utf8 source, signatures, and "no feature 'indirect'" by default

We can't make the "module" keyword visible without a feature flag. "use
VERSION" will still be needed and that enables all the nice stuff
anyway. Well, apart from "use utf8". It's been decided that it's a bad
default: https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html

> * :export is handled natively leaving the import() free for other uses

I don't see why a new keyword is needed for that. If we want ':export'
attribute (which is an interesting idea), it can be implemented without
the "module" keyword. Perl already supports attributes on subs and we
already have a few built-in ones (such as :const, :method etc.).

The "package" keyword currently doesn't take attributes, but I think it
can be changed. "package Foo :bar" is a syntax error, so it probably
doesn't conflict with anything.

We should be always wary of adding new keywords, especially the ones that
do the same thing as already existing keywords but slightly differently.
We will be stuck with both keywords forever. It will make the language
more complex and confusing.

Of course, I'm not saying we should never do this, but we must carefully
weigh the costs and benefits. In this case, I'm not convinced the
benefits are big enough.

>* Yields a `1` to avoid needing to add `1` at the end of every file.

I think we should get rid of that misfeature completely.

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