Mailing List Archive

Hi there,

On Thu, 4 Jan 2024, Paul "LeoNerd" Evans wrote:

> use meta;
> no warnings 'meta::experimental';
> ...

This seems by far the more natural to me.

--

73,
Ged.

On Thu, Jan 04, 2024 at 05:41:34PM +0000, Paul "LeoNerd" Evans wrote:
>
> The question becomes: What should that warning category be? Two
> obvious thoughts come to mind:
>
> * It could be `meta::experimental`, as its own module:
>
> use meta; no warnings 'meta::experimental';

This has the benefit of being below the "meta" namespace. Everything
is obvious.

> * It could borrow an area of core and be `experimental::meta`
>
> use meta; no warnings 'experimental::meta';

The "experimental::" namespace seems to be mostly used by experimental
features so far.

> In this latter idea, it would casually lead users to think that they
> could combine the whole lot by perhaps doing
>
> use experimental 'meta';

The current use-case for a `use experimental` line (e.g. `use
experimental 'signatures'`) is that it will be removed once the feature
is not experimental anymore in the declared bundle.

A piece of code using an experimental feature will evolve as such:

use v5.34;
use feature 'signatures';
no warnings 'experimental::signatures';

Which can be shortened to:

use v5.34;
use experimental 'signatures';

Once signatures are not experimental, it shrinks down to:

use v5.36;

So the `use experimental` line is meant to disappear eventually.


The `meta` modules is meant to be always be loaded explicitely, and is
not a feature. With an implicit `use meta`, once the experimental
warnings are dropped, one would have to replace `use experimental
'meta';` with `use meta;`. Doesn't look like much gain.

The evolution of your last proposal would look something like:

use v5.40;
use experimental 'meta';

becoming, once not experimental any more:

use v5.42;
use meta;

As opposed to:

use v5.40;
use meta;
no warnings 'meta::experimental';

becoming:

use v5.42;
use meta;

> Likely the first idea is best.

I agree with you.

--
Philippe Bruhat (BooK)

Treat those you outrank well... you never know when they will outrank you.
(Moral from Groo #7 (Image))

IMHO it should be:

use meta;
no warnings 'meta::experimental';

maybe even:
use meta -experimental;

later should be reserved for:
use feature 'meta';
no warnings 'experimental::meta';

On Thu, Jan 4, 2024 at 6:41?PM Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> The `meta` module continues its experimentation. The documentation does
> say "it's experimental", but likely it needs some actual runtime
> warnings adding to that effect.
>
> It seems the usual style would be for various functions and initial
> access points to print warnings in some category that can be silenced,
> allowing the developer to accept the experimental nature of it.
>
> The question becomes: What should that warning category be? Two obvious
> thoughts come to mind:
>
> * It could be `meta::experimental`, as its own module:
>
> use meta;
> no warnings 'meta::experimental';
> ...
>
> * It could borrow an area of core and be `experimental::meta`
>
> use meta;
> no warnings 'experimental::meta';
>
> In this latter idea, it would casually lead users to think that they
> could combine the whole lot by perhaps doing
>
> use experimental 'meta';
>
> However, as experimental.pm currently stands, that would not work. It
> would have to be modified to recognise that "meta" is the name of a
> brand new module that it ought to load first, to then disable the
> warning category. I'm not entirely sure about the feel of this, as it
> starts to conflate the idea of simple named features (as per
> `use feature ...`) and entire new modules - which in any case for older
> perls would just be installed from CPAN in the usual manner for
> external modules.
>
> Likely the first idea is best.
>
> Does anyone have any thoughts here?

As this is intended to be part of core, I think it should follow the
same pattern as all core experimental warnings, and be an
experimental::meta category.

meta is intended to be a module to be loaded, not something enabled
via feature.pm. In future code, you will still have to load meta,
while for features they will eventually be enabled via a use v5.xx
statement. Since future code will always want to explicitly load
meta.pm, I don't think experimental.pm should try to load meta.pm, and
should only disable the warnings.

This would present a small issue regarding ordering, and so it would
be good to modify experimental.pm to create the experimental::meta
category as needed.