Mailing List Archive

2022-6-7 7:07 Neil Bowers <neilb@neilb.org> wrote:

> This is a retrospective Pre-RFC for a proposal from Curtis, for which he
> submitted a draft RFC[1]. We nearly missed it when reviewing proposals
> in-flight in our PSC meeting last week, and decided to trigger a discussion
> here, to reinforce the process.
>
> ...
>
> [1] https://github.com/Perl/RFCs/pull/16
>
>
I want to hear the haarg' proposal a little more.

>There is another model that could be used. could always ignore the return
value from the file if the feature was enabled. This is simpler than the
previous option, but accomplishes essentially the same thing. It still
needs special handling in , but doesn't need to care about an implicit vs
explicit return. In practice, the return value from a ed file is not usable
for anything. The only impact it will have on perl's behavior is throwing
an error for a false value. This is better done by throwing a real error.
If there is no real purpose for returning an explicit value, why complicate
the model by trying to handle specially?

Does this mean changing the behavior of "use", "require", "do" in the
"yield_true"
feature?

On Mon, Jun 6, 2022 at 8:17 PM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
> 2022-6-7 7:07 Neil Bowers <neilb@neilb.org> wrote:
>
>> This is a retrospective Pre-RFC for a proposal from Curtis, for which he
>> submitted a draft RFC[1]. We nearly missed it when reviewing proposals
>> in-flight in our PSC meeting last week, and decided to trigger a discussion
>> here, to reinforce the process.
>>
>> ...
>>
>> [1] https://github.com/Perl/RFCs/pull/16
>>
>>
> I want to hear the haarg' proposal a little more.
>
> >There is another model that could be used. could always ignore the return
> value from the file if the feature was enabled. This is simpler than the
> previous option, but accomplishes essentially the same thing. It still
> needs special handling in , but doesn't need to care about an implicit vs
> explicit return. In practice, the return value from a ed file is not usable
> for anything. The only impact it will have on perl's behavior is throwing
> an error for a false value. This is better done by throwing a real error.
> If there is no real purpose for returning an explicit value, why complicate
> the model by trying to handle specially?
>
> Does this mean changing the behavior of "use", "require", "do" in the "yield_true"
> feature?
>
>
Yes, and the feature would need a different name.

I think it is overall a better idea, but practically, it may not be better
to implement.

The overall goal of this feature is so people no longer need to put "1;" at
the end of their module for no reason (as perceived by most users), or have
spurious errors if they forget to. For a user to accomplish this in their
module, they need a feature they can enable in their module, not in the
place it gets required.

If we only implement a feature to change how "require" behaves, users won't
be able to stop putting "1;" in their modules unless they can ensure their
module is only called by code using the new feature.

But there's also another option: we could do both. Though it seems a little
unnecessary for such a trivial feature.

-Dan

* Yuki Kimoto <kimoto.yuki@gmail.com> [2022-06-07 09:16:22 +0900]:

> 2022-6-7 7:07 Neil Bowers <neilb@neilb.org> wrote:
>
> > This is a retrospective Pre-RFC for a proposal from Curtis, for which he
> > submitted a draft RFC[1]. We nearly missed it when reviewing proposals
> > in-flight in our PSC meeting last week, and decided to trigger a discussion
> > here, to reinforce the process.
> >
> > ...
> >
> > [1] https://github.com/Perl/RFCs/pull/16
> >
> >
> I want to hear the haarg' proposal a little more.
>
> >There is another model that could be used. could always ignore the return
> value from the file if the feature was enabled. This is simpler than the
> previous option, but accomplishes essentially the same thing. It still
> needs special handling in , but doesn't need to care about an implicit vs
> explicit return. In practice, the return value from a ed file is not usable
> for anything. The only impact it will have on perl's behavior is throwing
> an error for a false value. This is better done by throwing a real error.
> If there is no real purpose for returning an explicit value, why complicate
> the model by trying to handle specially?
>
> Does this mean changing the behavior of "use", "require", "do" in the
> "yield_true"
> feature?

I can't find a good read on what the "1;" is for; I just know it needs
to be there and can be anything "truthy". I've even seen cheeky module
authors return "666;", which to be fair is true. However, upon reading
what I could find in perldocs and about, it seems that if it is a "1;"
or something else; C<use>, C<require>, and C<do> all need something to
say definitively that "here is the end of package Foo's scope". Would
that be a "feature" or just something internal that could mark the "end"
of a package scope when it hit something like the end of the file?

FWIW, I don't find this an issue; I've been doing it for along time. Maybe
what is needed a macro like "__END__" or a keyword like "egakcap;" that
simply returns something truthy. I mean the target audience seems to be
the human being who is perusing googlestackoverflow about "how to write
a Perl module" ... this seems more clear than either the "1;" or literally
nothing; and it's kind of unix-y.

package Foo;
...
...
egakcap Foo;

Or something a little heredoc-y:

package Foo;
...
...
Foo; # or for a little flexibility, __PACKAGE__

Or wouldn't this suffice?

package Foo;
...
...
package main;

Or perhaps just encourage the use of lexical blocks when defining packages.
Since that since to indicate precisely the area of scope that "1;" is
meant to disambiguate (at the end of a file?).

I know this is about removing the "need" for "1;" but I think the real
need is to provide a more obvious "end of package scope" marker, which
ultimately really just needs to return a truthy value.

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Tue, Jun 7, 2022 at 12:11 AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> * Yuki Kimoto <kimoto.yuki@gmail.com> [2022-06-07 09:16:22 +0900]:
>
> > 2022-6-7 7:07 Neil Bowers <neilb@neilb.org> wrote:
> >
> > > This is a retrospective Pre-RFC for a proposal from Curtis, for which
> he
> > > submitted a draft RFC[1]. We nearly missed it when reviewing proposals
> > > in-flight in our PSC meeting last week, and decided to trigger a
> discussion
> > > here, to reinforce the process.
> > >
> > > ...
> > >
> > > [1] https://github.com/Perl/RFCs/pull/16
> > >
> > >
> > I want to hear the haarg' proposal a little more.
> >
> > >There is another model that could be used. could always ignore the
> return
> > value from the file if the feature was enabled. This is simpler than the
> > previous option, but accomplishes essentially the same thing. It still
> > needs special handling in , but doesn't need to care about an implicit vs
> > explicit return. In practice, the return value from a ed file is not
> usable
> > for anything. The only impact it will have on perl's behavior is throwing
> > an error for a false value. This is better done by throwing a real error.
> > If there is no real purpose for returning an explicit value, why
> complicate
> > the model by trying to handle specially?
> >
> > Does this mean changing the behavior of "use", "require", "do" in the
> > "yield_true"
> > feature?
>
> I can't find a good read on what the "1;" is for; I just know it needs
> to be there and can be anything "truthy". I've even seen cheeky module
> authors return "666;", which to be fair is true. However, upon reading
> what I could find in perldocs and about, it seems that if it is a "1;"
> or something else; C<use>, C<require>, and C<do> all need something to
> say definitively that "here is the end of package Foo's scope". Would
> that be a "feature" or just something internal that could mark the "end"
> of a package scope when it hit something like the end of the file?


It does not affect scope or the package in any way. It is the return value
of the required file.

-Dan

* Dan Book <grinnz@gmail.com> [2022-06-07 00:16:30 -0400]:

> On Tue, Jun 7, 2022 at 12:11 AM Oodler 577 via perl5-porters <
> perl5-porters@perl.org> wrote:
>
> > * Yuki Kimoto <kimoto.yuki@gmail.com> [2022-06-07 09:16:22 +0900]:
> >
> > > 2022-6-7 7:07 Neil Bowers <neilb@neilb.org> wrote:
> > >
> > > > This is a retrospective Pre-RFC for a proposal from Curtis, for which
> > he
> > > > submitted a draft RFC[1]. We nearly missed it when reviewing proposals
> > > > in-flight in our PSC meeting last week, and decided to trigger a
> > discussion
> > > > here, to reinforce the process.
> > > >
> > > > ...
> > > >
> > > > [1] https://github.com/Perl/RFCs/pull/16
> > > >
> > > >
> > > I want to hear the haarg' proposal a little more.
> > >
> > > >There is another model that could be used. could always ignore the
> > return
> > > value from the file if the feature was enabled. This is simpler than the
> > > previous option, but accomplishes essentially the same thing. It still
> > > needs special handling in , but doesn't need to care about an implicit vs
> > > explicit return. In practice, the return value from a ed file is not
> > usable
> > > for anything. The only impact it will have on perl's behavior is throwing
> > > an error for a false value. This is better done by throwing a real error.
> > > If there is no real purpose for returning an explicit value, why
> > complicate
> > > the model by trying to handle specially?
> > >
> > > Does this mean changing the behavior of "use", "require", "do" in the
> > > "yield_true"
> > > feature?
> >
> > I can't find a good read on what the "1;" is for; I just know it needs
> > to be there and can be anything "truthy". I've even seen cheeky module
> > authors return "666;", which to be fair is true. However, upon reading
> > what I could find in perldocs and about, it seems that if it is a "1;"
> > or something else; C<use>, C<require>, and C<do> all need something to
> > say definitively that "here is the end of package Foo's scope". Would
> > that be a "feature" or just something internal that could mark the "end"
> > of a package scope when it hit something like the end of the file?
>
>
> It does not affect scope or the package in any way. It is the return value
> of the required file.

Oh, gotcha. This seems like a non-issue, akin to advocating we not use periods
in the last sentence of every paragraph for something kind of related to
children finding it difficult to understand why you'd want that or the rationale
used to argue in favor of eliminating the Oxford Comma.

It just makes things more ambiguous, dazed and confused

Cheers,
Brett

>
> -Dan

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Tue, Jun 07, 2022 at 09:16:22AM +0900, Yuki Kimoto wrote:
> 2022-6-7 7:07 Neil Bowers <neilb@neilb.org> wrote:
>
> > This is a retrospective Pre-RFC for a proposal from Curtis, for which he
> > submitted a draft RFC[1]. We nearly missed it when reviewing proposals
> > in-flight in our PSC meeting last week, and decided to trigger a discussion
> > here, to reinforce the process.
> >
> > ...
> >
> > [1] https://github.com/Perl/RFCs/pull/16
> >
> >
> I want to hear the haarg' proposal a little more.
>
> >There is another model that could be used. could always ignore the return
> value from the file if the feature was enabled. This is simpler than the
> previous option, but accomplishes essentially the same thing. It still
> needs special handling in , but doesn't need to care about an implicit vs
> explicit return. In practice, the return value from a ed file is not usable
> for anything. The only impact it will have on perl's behavior is throwing
> an error for a false value. This is better done by throwing a real error.
> If there is no real purpose for returning an explicit value, why complicate
> the model by trying to handle specially?
>
> Does this mean changing the behavior of "use", "require", "do" in the
> "yield_true"
> feature?

There would be no change for "do", it doesn't require truthiness.

Simply removing the requirement is close to trivial (below), but I'd
expect it to break some downstream tests. It breaks a small number of
tests in core, including one for parent.pm.

Tony

diff --git a/pp_ctl.c b/pp_ctl.c
index 86f5f2c343..3f4fe43a15 100644
--- a/pp_ctl.c
+++ b/pp_ctl.c
@@ -1702,22 +1702,13 @@ S_pop_eval_context_maybe_croak(pTHX_ PERL_CONTEXT *cx, SV *errsv, int action)
CX_POP(cx);

if (do_croak) {
- const char *fmt;
HV *inc_hv = GvHVn(PL_incgv);

- if (action == 1) {
- (void)hv_delete_ent(inc_hv, namesv, G_DISCARD, 0);
- fmt = "%" SVf " did not return a true value";
- errsv = namesv;
- }
- else {
(void)hv_store_ent(inc_hv, namesv, &PL_sv_undef, 0);
- fmt = "%" SVf "Compilation failed in require";
if (!errsv)
errsv = newSVpvs_flags("Unknown error\n", SVs_TEMP);
- }

- Perl_croak(aTHX_ fmt, SVfARG(errsv));
+ Perl_croak(aTHX_ "%" SVf "Compilation failed in require", SVfARG(errsv));
}
}

@@ -4610,7 +4601,6 @@ PP(pp_leaveeval)
U8 gimme;
PERL_CONTEXT *cx;
OP *retop;
- int failed;
CV *evalcv;
bool keep;

@@ -4622,11 +4612,6 @@ PP(pp_leaveeval)
oldsp = PL_stack_base + cx->blk_oldsp;
gimme = cx->blk_gimme;

- /* did require return a false value? */
- failed = CxOLD_OP_TYPE(cx) == OP_REQUIRE
- && !(gimme == G_SCALAR
- ? SvTRUE_NN(*PL_stack_sp)
- : PL_stack_sp > oldsp);

if (gimme == G_VOID) {
PL_stack_sp = oldsp;
@@ -4654,7 +4639,7 @@ PP(pp_leaveeval)
CvDEPTH(evalcv) = 0;

/* pop the CXt_EVAL, and if a require failed, croak */
- S_pop_eval_context_maybe_croak(aTHX_ cx, NULL, failed);
+ S_pop_eval_context_maybe_croak(aTHX_ cx, NULL, 0);

if (!keep)
CLEAR_ERRSV();

What would the effect of yield_true be on a Perl source file used as simple
configuration data like the following, which I have actually practiced...

Contents of file config.pl:

use 5.38; # includes yield_true
my $config_rh = {...}; # last statement

Contents of program using it:

...
my $config_rh = do 'config.pl';
...

Note that I wrote the above from memory of something I did a couple decades ago,
it may not be correct, but should have the right idea.

The point is, if yield_true is in effect, would it break the above usage pattern
and result in the main program $config_rh containing true rather than the
intended hash ref of config data?

Or is yield_true intended to apply in more limited circumstances than all
compiled Perl files?

-- Darren Duncan

On Tue, Jun 7, 2022 at 1:59 AM Tony Cook <tony@develop-help.com> wrote:

> There would be no change for "do", it doesn't require truthiness.
>

C<do> actually does require the return of a true value if you want to
detect failures.

do(...) or die $!; # File not found, etc
die $@ if $@; # Syntax error, runtime exception, etc

On Tue, Jun 7, 2022 at 11:53 AM Eric Brine <ikegami@adaelis.com> wrote:

> On Tue, Jun 7, 2022 at 1:59 AM Tony Cook <tony@develop-help.com> wrote:
>
>> There would be no change for "do", it doesn't require truthiness.
>>
>
> C<do> actually does require the return of a true value if you want to
> detect failures.
>
> do(...) or die $!; # File not found, etc
> die $@ if $@; # Syntax error, runtime exception, etc
>
>
That's only due to the deficiencies of the do() API and the convention you
wrote - not an intrinsic part of the API. do can still be used on a file
that returns false if you don't perform that particular check.

-Dan

On Tue, Jun 7, 2022 at 5:06 AM Darren Duncan <darren@darrenduncan.net>
wrote:

> What would the effect of yield_true be on a Perl source file used as
> simple
> configuration data like the following, which I have actually practiced...
>

No effect. This is only for require (and thus use).

-Dan

On Tue, Jun 7, 2022 at 12:55 PM Dan Book <grinnz@gmail.com> wrote:

> On Tue, Jun 7, 2022 at 11:53 AM Eric Brine <ikegami@adaelis.com> wrote:
>
>> On Tue, Jun 7, 2022 at 1:59 AM Tony Cook <tony@develop-help.com> wrote:
>>
>>> There would be no change for "do", it doesn't require truthiness.
>>>
>>
>> C<do> actually does require the return of a true value if you want to
>> detect failures.
>>
>> do(...) or die $!; # File not found, etc
>> die $@ if $@; # Syntax error, runtime exception, etc
>>
>>
> That's only due to the deficiencies of the do() API and the convention you
> wrote - not an intrinsic part of the API. do can still be used on a file
> that returns false if you don't perform that particular check.
>

There is no alternate check if you want an error message. And it would be
rather silly not to provide a useful error message. So there's really no
other way to use it. So I was pretty gracious when I didn't limit myself to
saying " C<do> actually does require the return of a true value".

On Tue, Jun 7, 2022 at 2:21 PM Eric Brine <ikegami@adaelis.com> wrote:

> On Tue, Jun 7, 2022 at 12:55 PM Dan Book <grinnz@gmail.com> wrote:
>
>> On Tue, Jun 7, 2022 at 11:53 AM Eric Brine <ikegami@adaelis.com> wrote:
>>
>>> On Tue, Jun 7, 2022 at 1:59 AM Tony Cook <tony@develop-help.com> wrote:
>>>
>>>> There would be no change for "do", it doesn't require truthiness.
>>>>
>>>
>>> C<do> actually does require the return of a true value if you want to
>>> detect failures.
>>>
>>> do(...) or die $!; # File not found, etc
>>> die $@ if $@; # Syntax error, runtime exception, etc
>>>
>>>
>> That's only due to the deficiencies of the do() API and the convention
>> you wrote - not an intrinsic part of the API. do can still be used on a
>> file that returns false if you don't perform that particular check.
>>
>
> There is no alternate check if you want an error message. And it would be
> rather silly not to provide a useful error message. So there's really no
> other way to use it. So I was pretty gracious when I didn't limit myself to
> saying " C<do> actually does require the return of a true value".
>

Well, you could return a true value by something other means. Like
returning a defined value and using C<defined(do())> (as per the docs), or
setting some var and checking the var. So one needs to return a true value,
but it doesn't have to be the final value of the script.

I also feel these two are different features.

2022-6-7 9:40 Dan Book <grinnz@gmail.com> wrote:

> On Mon, Jun 6, 2022 at 8:17 PM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
>>
>> 2022-6-7 7:07 Neil Bowers <neilb@neilb.org> wrote:
>>
>>> This is a retrospective Pre-RFC for a proposal from Curtis, for which he
>>> submitted a draft RFC[1]. We nearly missed it when reviewing proposals
>>> in-flight in our PSC meeting last week, and decided to trigger a discussion
>>> here, to reinforce the process.
>>>
>>> ...
>>>
>>> [1] https://github.com/Perl/RFCs/pull/16
>>>
>>>
>> I want to hear the haarg' proposal a little more.
>>
>> >There is another model that could be used. could always ignore the
>> return value from the file if the feature was enabled. This is simpler than
>> the previous option, but accomplishes essentially the same thing. It still
>> needs special handling in , but doesn't need to care about an implicit vs
>> explicit return. In practice, the return value from a ed file is not usable
>> for anything. The only impact it will have on perl's behavior is throwing
>> an error for a false value. This is better done by throwing a real error.
>> If there is no real purpose for returning an explicit value, why complicate
>> the model by trying to handle specially?
>>
>> Does this mean changing the behavior of "use", "require", "do" in the "yield_true"
>> feature?
>>
>>
> Yes, and the feature would need a different name.
>
> I think it is overall a better idea, but practically, it may not be better
> to implement.
>
> The overall goal of this feature is so people no longer need to put "1;"
> at the end of their module for no reason (as perceived by most users), or
> have spurious errors if they forget to. For a user to accomplish this in
> their module, they need a feature they can enable in their module, not in
> the place it gets required.
>
> If we only implement a feature to change how "require" behaves, users
> won't be able to stop putting "1;" in their modules unless they can ensure
> their module is only called by code using the new feature.
>
> But there's also another option: we could do both. Though it seems a
> little unnecessary for such a trivial feature.
>
> -Dan
>

2022-6-8 0:56 Dan Book <grinnz@gmail.com> wrote:

> On Tue, Jun 7, 2022 at 5:06 AM Darren Duncan <darren@darrenduncan.net>
> wrote:
>
>> What would the effect of yield_true be on a Perl source file used as
>> simple
>> configuration data like the following, which I have actually practiced...
>>
>
> No effect. This is only for require (and thus use).
>
> -Dan
>

"yield_true" feature doesn't affect "do".

Does this mean "yield_true" is not simple syntax sugar at the end of "1"?

Does the following code work well?

# Foo.pm
use feature 'yield_true';

undef

# do - $ret is undef
my $ret = do 'Foo.pm';

# require - OK
require 'Foo.pm';

* Yuki Kimoto <kimoto.yuki@gmail.com> [2022-06-08 17:47:27 +0900]:

> 2022-6-8 0:56 Dan Book <grinnz@gmail.com> wrote:
>
> > On Tue, Jun 7, 2022 at 5:06 AM Darren Duncan <darren@darrenduncan.net>
> > wrote:
> >
> >> What would the effect of yield_true be on a Perl source file used as
> >> simple
> >> configuration data like the following, which I have actually practiced...
> >>
> >
> > No effect. This is only for require (and thus use).
> >
> > -Dan
> >
>
> "yield_true" feature doesn't affect "do".
>
> Does this mean "yield_true" is not simple syntax sugar at the end of "1"?

This is beginning to sound like Test::More.

use Test::More tests => 42;
...

or

use Test::More;

...

done_testing;

So maybe follow that kind of pattern. But I am still lost why
typing "use feature 'yield_true';" is better than "1;".

Looking back at the pre-RFC itself, I don't think the "motivation"
is sufficiently, developed.

"Eliminate the need for a true value at the end of a Perl file."

Okay, but why?

>
> Does the following code work well?

idk.

>
> # Foo.pm
> use feature 'yield_true';
>
> undef
>
> # do - $ret is undef
> my $ret = do 'Foo.pm';
>
> # require - OK
> require 'Foo.pm';

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Wed, Jun 8, 2022 at 10:56 PM Oodler 577 <oodler577@sdf-eu.org> wrote:

> * Yuki Kimoto <kimoto.yuki@gmail.com> [2022-06-08 17:47:27 +0900]:
>
> > 2022-6-8 0:56 Dan Book <grinnz@gmail.com> wrote:
> >
> > > On Tue, Jun 7, 2022 at 5:06 AM Darren Duncan <darren@darrenduncan.net>
> > > wrote:
> > >
> > >> What would the effect of yield_true be on a Perl source file used as
> > >> simple
> > >> configuration data like the following, which I have actually
> practiced...
> > >>
> > >
> > > No effect. This is only for require (and thus use).
> > >
> > > -Dan
> > >
> >
> > "yield_true" feature doesn't affect "do".
> >
> > Does this mean "yield_true" is not simple syntax sugar at the end of "1"?
>
> This is beginning to sound like Test::More.
>
> use Test::More tests => 42;
> ...
>
> or
>
> use Test::More;
>
> ...
>
> done_testing;
>
> So maybe follow that kind of pattern. But I am still lost why
> typing "use feature 'yield_true';" is better than "1;".
>

> This is not a feature we’d expect people to use explicitly, but would be
part of the version bundle, so you’d get it for free with a future `use
v5.XY`.

-Dan

* Dan Book <grinnz@gmail.com> [2022-06-08 23:32:32 -0400]:

> On Wed, Jun 8, 2022 at 10:56 PM Oodler 577 <oodler577@sdf-eu.org> wrote:
>
> > * Yuki Kimoto <kimoto.yuki@gmail.com> [2022-06-08 17:47:27 +0900]:
> >
> > > 2022-6-8 0:56 Dan Book <grinnz@gmail.com> wrote:
> > >
> > > > On Tue, Jun 7, 2022 at 5:06 AM Darren Duncan <darren@darrenduncan.net>
> > > > wrote:
> > > >
> > > >> What would the effect of yield_true be on a Perl source file used as
> > > >> simple
> > > >> configuration data like the following, which I have actually
> > practiced...
> > > >>
> > > >
> > > > No effect. This is only for require (and thus use).
> > > >
> > > > -Dan
> > > >
> > >
> > > "yield_true" feature doesn't affect "do".
> > >
> > > Does this mean "yield_true" is not simple syntax sugar at the end of "1"?
> >
> > This is beginning to sound like Test::More.
> >
> > use Test::More tests => 42;
> > ...
> >
> > or
> >
> > use Test::More;
> >
> > ...
> >
> > done_testing;
> >
> > So maybe follow that kind of pattern. But I am still lost why
> > typing "use feature 'yield_true';" is better than "1;".
> >
>
> > This is not a feature we?d expect people to use explicitly, but would be
> part of the version bundle, so you?d get it for free with a future `use
> v5.XY`.

Okay, thank you for your continued patience.

Final thought:

I guess frankly speaking this seems like it's just going to cause
confusion among long timers and provide no benefit to new comers.

A fair compromise would be a combination of,

* improved documentation on the feature behind the "1;"
boiler plate (because TBH I don't know what a false-y
value there would allow one to do or not do).

* something meaningful like Test::More's "done_testing;" that
can actually benefit new users. Like something I mentioned
before just to make the point, "egakcap" ('package' backwards),
but then again why bother when this works (upon testing):

package test; # does work like this noaw

# ... pkg stuff

__PACKAGE__

And just spitballing here, but what would happen if C<__END__>
got converted to that "1;"? As far as I know it's just tells
the interpreter "no more code past here" - so what better way
to be assured that a "1;" is okay?

package test; # doesn't actually work like this

# ... pkg stuff

__END__

But what about putting nothing? I think that's a terrible idea
on account of the decades of having to do that. I put it in the
same camp as removing sigils or semi-colons.

Cheers,
Brett
>
> -Dan

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

2022-6-7 9:40 Dan Book <grinnz@gmail.com> wrote:

>
> But there's also another option: we could do both. Though it seems a
> little unnecessary for such a trivial feature.
>
> -Dan
>

I write the idea that the effect is as little as possible.

A flag "REQUIRE_NOT_CHECK_RETURN_VALUE" is added to the block (file scope)
of loaded file in the feature "yeald_true".

op_file_scope_block->flag |= REQUIRE_NOT_CHECK_RETURN_VALUE

And if "require" finds the flag "REQUIRE_NOT_CHECK_RETURN_VALUE" in the
feature "require_not_check_return_value", "require" doesn't see the return
value.

# Foo.pm
package Foo;
use feature 'yeald_true';

undef;

# main.pl
use feature 'require_not_check_return_value';
require Foo;

If a user want the original behavior of "require", he do "no feature
'require_not_check_return_value'"

no feature 'require_not_check_return_value'
require Foo;

Hi Brett,

> So maybe follow that kind of pattern. But I am still lost why
> typing "use feature 'yield_true';" is better than "1;".

As noted in the pre-RFC, and in Curtis’s draft RFC, the end-game is not to have people type

    use feature 'yield_true';

But for the feature to be included in the version bundle, so at the top of your module you just write:

    package Example;
    use v5.38;

And then you don’t have to put the 1; at the end.


> Looking back at the pre-RFC itself, I don't think the "motivation"
> is sufficiently, developed.

As noted in the Pre-RFC, the requirement to add "1;" confuses people. And they might look at the code for CPAN modules and see humorous return values, and be further confused.

Here’s an example. Someone writes the following module:

    package Example;
    use v5.36;
    use parent 'Exporter';
    our @EXPORT_OK = qw/ hello_world /;
    sub hello_world { print "hello, world\n"; }

They use it from a script, and it works fine.
They’re expanding it, and they start off by adding the following line after the EXPORT_OK line:

    my $secret = 0;

Now when they run their test script, they get an error:

    Example.pm did not return a true value at example.pl line 6.

Huh? They look at their module, and line 6 is where they declared the sub, which was fine before, and they’ve not touched it. It just happens that the last value returned by loading that module is now 0.

If they know to look at perldiag, they’d find an explanation, or if they google "perl did not return a true value" they’d also find the answer.

Instead of returning 0 to signify an initialisation failure, I think it’s better to throw an exception (die), and not require this quirky true value at the end of your modules.

Yes, it’s only a small thing, but the cumulative effect of addressing small quirks like this is a more welcoming / less confusing language for beginners and casual programmers. We’d never expect people to use this feature explicitly, it just becomes part of "latest and greatest Perl".

Neil

I understand the implementation now by reading the true.xs.

https://metacpan.org/release/CHOCOLATE/true-v1.0.2/source/true.xs

Only If the file is loaded from require, true value is added to the end of
file.

On Mon, 6 Jun 2022 23:05:59 +0100
Neil Bowers <neilb@neilb.org> wrote:

> This is a retrospective Pre-RFC for a proposal from Curtis, for which
> he submitted a draft RFC[1].
>
> [1] https://github.com/Perl/RFCs/pull/16

haarg then defines[2] three possible ways that such a feature might
work in practice, summarized as:

1. Implicit return value is ignored and `true` is substituted instead

2. The surrounding `require` would ignore the implicit return value
and behave as if `true` had been returned

3. The surrounding `require` would ignore *any* return value (whether
implicit because of EOF, or explicit from `return`), and behave as
if `true` had been returned

[2]: https://github.com/Perl/RFCs/pull/16#issuecomment-1087450017

Option 1 differs from options 2 and 3 in that option 1 is more about
the implied meaning of the contents of the loaded file itself, whereas
options 2 and 3 affect only what `require` will do with that
information. This matters because sometimes code uses `do` on a file
instead, and expects the resulting value obtained from it to be
meaningful (e.g. as configuration or similar). Option 1 would affect
that usecase, whereas options 2 and 3 would not.

Option 3 differs from options 1 and 2 when we consider the current
behaviour that modules can *explicitly* `return false` to signal a
particular kind of error, distinct from actually `die`ing. (In brief:
it has to do with whether subsequent attempts to `require` the file
again will result in another compilation attempt, or simply rethrow the
previous failure). haarg also comments:

> I'm not particularly convinced that allowing the module to be
> recompiled is a useful feature, so I don't think the "return false"
> behavior needs to be facilitated under this feature. But others may
> disagree, and this would argue against the third option I proposed
> above.

I agree; I don't think allowing recompilation is useful. In the rare
event that maybe some module did want to do that, perhaps it could
specifically signal this with

no feature yield_true;
return 0; # request recompilation

The vastly-common case would not want to do that, so it seems most
expedient not to consider it here.

Therefore I think we should go with option 3; which would involve
altering the implementation of `require` to just ignore the return
value of the loaded file if `feature 'yield_true'` was in effect by the
time it reached EOF and hadn't already thrown an exception by that time.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Fri, Jun 10, 2022 at 8:22 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> 3. The surrounding `require` would ignore *any* return value (whether
> implicit because of EOF, or explicit from `return`), and behave as
> if `true` had been returned
>

Can someone show an example, ideally on CPAN, where this gets used?

> Can someone show an example, ideally on CPAN, where this gets used?

I _think_ you were asking for an example of someone using the return value from a require. In which case:

https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm

This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):

    if ( $] >= 5.006 && $] < 5.007003  ) {
        eval { $data = require 'unicode/Name.pl'; };
    }
    elsif ( $] >= 5.007003 ) {
        eval { $data = require 'unicore/Name.pl'; };

        # since v5.11.3, unicore/Name.pl creates subroutines
        # they end up in our namespace, so get rid of them
        undef *code_point_to_name_special;
        undef *name_to_code_point_special;
    }

Guessing there may be other examples on CPAN – this is just the first one I found with grep.metacpan.org.

Neil

Op 11-06-2022 om 10:37 schreef Neil Bowers:
> > Can someone show an example, ideally on CPAN, where this gets used?
>
> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> <https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm>
>
> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>
>     if ( $] >= 5.006 && $] < 5.007003  ) {
>         eval { $data = require 'unicode/Name.pl'; };
>     }
>     elsif ( $] >= 5.007003 ) {
>         eval { $data = require 'unicore/Name.pl'; };
>
>         # since v5.11.3, unicore/Name.pl creates subroutines
>         # they end up in our namespace, so get rid of them
>         undef *code_point_to_name_special;
>         undef *name_to_code_point_special;
>     }
>
> Guessing there may be other examples on CPAN – this is just the first
> one I found with grep.metacpan.org.
>

I'm not sure if that is what Neil ment, because is this really supposed
to work? The documentation for require says nothing about it returning a
value. I would say that if this works it is accidental.

I think that Neil ment an example of where not returning a true value
from a module is used for some decission making (using try/eval) instead
of aborting compilation.

M4

On 6/11/22 02:37, Neil Bowers wrote:
> > Can someone show an example, ideally on CPAN, where this gets used?
>
> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> <https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm>
>
> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>
>     if ( $] >= 5.006 && $] < 5.007003  ) {
>         eval { $data = require 'unicode/Name.pl'; };
>     }
>     elsif ( $] >= 5.007003 ) {
>         eval { $data = require 'unicore/Name.pl'; };
>
>         # since v5.11.3, unicore/Name.pl creates subroutines
>         # they end up in our namespace, so get rid of them
>         undef *code_point_to_name_special;
>         undef *name_to_code_point_special;
>     }

I feel compelled to point out that the file read-in in this example,
unicore/Name.pl, has the following text at its top

# !!!!!!! INTERNAL PERL USE ONLY !!!!!!!
# This file is for internal use by core Perl only. The format and even the
# name or existence of this file are subject to change without notice.
Don't
# use it directly. Use Unicode::UCD to access the Unicode character data
# base.


top of says:

2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

>
> 3. The surrounding `require` would ignore *any* return value (whether
> implicit because of EOF, or explicit from `return`), and behave as
> if `true` had been returned
>
> Therefore I think we should go with option 3; which would involve
> altering the implementation of `require` to just ignore the return
> value of the loaded file if `feature 'yield_true'` was in effect by the
> time it reached EOF and hadn't already thrown an exception by that time.
>
>
A problem of 3 is that a new module which has no "1;" at the end can't be
loaded from old codes.

I think 3 is good, however a little adjustment is needed.

2022-6-13 11:02 Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
>
> 2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
>>
>> 3. The surrounding `require` would ignore *any* return value (whether
>> implicit because of EOF, or explicit from `return`), and behave as
>> if `true` had been returned
>>
>> Therefore I think we should go with option 3; which would involve
>> altering the implementation of `require` to just ignore the return
>> value of the loaded file if `feature 'yield_true'` was in effect by the
>> time it reached EOF and hadn't already thrown an exception by that time.
>>
>>
> A problem of 3 is that a new module which has no "1;" at the end can't be
> loaded from old codes.
>
> I think 3 is good, however a little adjustment is needed.
>

> Therefore I think we should go with option 3; which would involve
altering the implementation of `require` to just ignore the return
value of the loaded file if `feature 'yield_true'` was in effect by the
time it reached EOF and hadn't already thrown an exception by that time.

I think this seems to be the 4th choice from the perspective of both
changing "require" and implementing "yield_true" feature.

On Mon, Jun 13, 2022 at 4:02 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
>
> 2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
>>
>> 3. The surrounding `require` would ignore *any* return value (whether
>> implicit because of EOF, or explicit from `return`), and behave as
>> if `true` had been returned
>>
>> Therefore I think we should go with option 3; which would involve
>> altering the implementation of `require` to just ignore the return
>> value of the loaded file if `feature 'yield_true'` was in effect by the
>> time it reached EOF and hadn't already thrown an exception by that time.
>>
>>
> A problem of 3 is that a new module which has no "1;" at the end can't be
> loaded from old codes.
>
> I think 3 is good, however a little adjustment is needed.
>

As a module using this feature would require v5.38 this is a non-problem.

On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:

> > Can someone show an example, ideally on CPAN, where this gets used?
>
> I _think_ you were asking for an example of someone using the return value
> from a require. In which case:
>
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>
> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>
> if ( $] >= 5.006 && $] < 5.007003 ) {
> eval { $data = require 'unicode/Name.pl'; };
> }
> elsif ( $] >= 5.007003 ) {
> eval { $data = require 'unicore/Name.pl'; };
>
> # since v5.11.3, unicore/Name.pl creates subroutines
> # they end up in our namespace, so get rid of them
> undef *code_point_to_name_special;
> undef *name_to_code_point_special;
> }
>
> Guessing there may be other examples on CPAN – this is just the first one
> I found with grep.metacpan.org.
>
> Neil
>
>

Thanks for the grep.metacpan.org link, haven't thought about it for finding
examples. I've looked at some others and using the return value of a
require call is used quite frequently. So option 3 isn't a good one in my
opinion, as a module changed to use the feature, most probably with 'use
v5.38;' not thinking about the enabled feature, which would lead to another
module failing because of the changed behavior.

On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
>>
>> > Can someone show an example, ideally on CPAN, where this gets used?
>>
>> I _think_ you were asking for an example of someone using the return value from a require. In which case:
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>>
>> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>>
>> if ( $] >= 5.006 && $] < 5.007003 ) {
>> eval { $data = require 'unicode/Name.pl'; };
>> }
>> elsif ( $] >= 5.007003 ) {
>> eval { $data = require 'unicore/Name.pl'; };
>>
>> # since v5.11.3, unicore/Name.pl creates subroutines
>> # they end up in our namespace, so get rid of them
>> undef *code_point_to_name_special;
>> undef *name_to_code_point_special;
>> }
>>
>> Guessing there may be other examples on CPAN – this is just the first one I found with grep.metacpan.org.
>>
>> Neil
>>
>
>
> Thanks for the grep.metacpan.org link, haven't thought about it for finding examples. I've looked at some others and using the return value of a require call is used quite frequently. So option 3 isn't a good one in my opinion, as a module changed to use the feature, most probably with 'use v5.38;' not thinking about the enabled feature, which would lead to another module failing because of the changed behavior.

Anything relying on the return value of require as being anything
other than true is already broken. The second time require is called
for a module, it will turn true, not whatever the module tried to
return. unicode/Name.pl is meant to be loaded via do, not require, in
addition to being internal only.

Going back to perl 5.30, the last version Acme::MetaSyntactic passed
its tests on, it still fails if you cause Name.pl to be loaded early.

$ perl -e'use strict; use warnings; use charnames qw(greek); use
Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
die "no names!" if !$meta->name;'
no names! at -e line 1.

I'd say it's better to cause these things to always fail, rather than
allowing them to sometimes appear to work.

On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:

> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
> >>
> >> > Can someone show an example, ideally on CPAN, where this gets used?
> >>
> >> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
> >>
> >>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> >>
> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
> >>
> >> if ( $] >= 5.006 && $] < 5.007003 ) {
> >> eval { $data = require 'unicode/Name.pl'; };
> >> }
> >> elsif ( $] >= 5.007003 ) {
> >> eval { $data = require 'unicore/Name.pl'; };
> >>
> >> # since v5.11.3, unicore/Name.pl creates subroutines
> >> # they end up in our namespace, so get rid of them
> >> undef *code_point_to_name_special;
> >> undef *name_to_code_point_special;
> >> }
> >>
> >> Guessing there may be other examples on CPAN – this is just the first
> one I found with grep.metacpan.org.
> >>
> >> Neil
> >>
> >
> >
> > Thanks for the grep.metacpan.org link, haven't thought about it for
> finding examples. I've looked at some others and using the return value of
> a require call is used quite frequently. So option 3 isn't a good one in my
> opinion, as a module changed to use the feature, most probably with 'use
> v5.38;' not thinking about the enabled feature, which would lead to another
> module failing because of the changed behavior.
>
> Anything relying on the return value of require as being anything
> other than true is already broken. The second time require is called
> for a module, it will turn true, not whatever the module tried to
> return. unicode/Name.pl is meant to be loaded via do, not require, in
> addition to being internal only.
>
> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
> its tests on, it still fails if you cause Name.pl to be loaded early.
>
> $ perl -e'use strict; use warnings; use charnames qw(greek); use
> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
> die "no names!" if !$meta->name;'
> no names! at -e line 1.
>
> I'd say it's better to cause these things to always fail, rather than
> allowing them to sometimes appear to work.
>

Look at some of the other modules using the return value of require from
the grep.metacpan.org link.

2022-6-13 18:37 Alexander Hartmaier <alex.hartmaier@gmail.com> wrote:

> On Mon, Jun 13, 2022 at 4:02 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
>>
>>
>> 2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>
>>>
>>> 3. The surrounding `require` would ignore *any* return value (whether
>>> implicit because of EOF, or explicit from `return`), and behave as
>>> if `true` had been returned
>>>
>>> Therefore I think we should go with option 3; which would involve
>>> altering the implementation of `require` to just ignore the return
>>> value of the loaded file if `feature 'yield_true'` was in effect by the
>>> time it reached EOF and hadn't already thrown an exception by that time.
>>>
>>>
>> A problem of 3 is that a new module which has no "1;" at the end can't be
>> loaded from old codes.
>>
>> I think 3 is good, however a little adjustment is needed.
>>
>
> As a module using this feature would require v5.38 this is a non-problem.
>

That is true. It was my misunderstanding.

On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:
>>
>> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
>> >>
>> >> > Can someone show an example, ideally on CPAN, where this gets used?
>> >>
>> >> I _think_ you were asking for an example of someone using the return value from a require. In which case:
>> >>
>> >> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>> >>
>> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>> >>
>> >> if ( $] >= 5.006 && $] < 5.007003 ) {
>> >> eval { $data = require 'unicode/Name.pl'; };
>> >> }
>> >> elsif ( $] >= 5.007003 ) {
>> >> eval { $data = require 'unicore/Name.pl'; };
>> >>
>> >> # since v5.11.3, unicore/Name.pl creates subroutines
>> >> # they end up in our namespace, so get rid of them
>> >> undef *code_point_to_name_special;
>> >> undef *name_to_code_point_special;
>> >> }
>> >>
>> >> Guessing there may be other examples on CPAN – this is just the first one I found with grep.metacpan.org.
>> >>
>> >> Neil
>> >>
>> >
>> >
>> > Thanks for the grep.metacpan.org link, haven't thought about it for finding examples. I've looked at some others and using the return value of a require call is used quite frequently. So option 3 isn't a good one in my opinion, as a module changed to use the feature, most probably with 'use v5.38;' not thinking about the enabled feature, which would lead to another module failing because of the changed behavior.
>>
>> Anything relying on the return value of require as being anything
>> other than true is already broken. The second time require is called
>> for a module, it will turn true, not whatever the module tried to
>> return. unicode/Name.pl is meant to be loaded via do, not require, in
>> addition to being internal only.
>>
>> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
>> its tests on, it still fails if you cause Name.pl to be loaded early.
>>
>> $ perl -e'use strict; use warnings; use charnames qw(greek); use
>> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
>> die "no names!" if !$meta->name;'
>> no names! at -e line 1.
>>
>> I'd say it's better to cause these things to always fail, rather than
>> allowing them to sometimes appear to work.
>
>
> Look at some of the other modules using the return value of require from the grep.metacpan.org link.

Do you have a concrete example?

For most cases I saw, changing the module or file to always return
true (as in !!1) would either not make any difference, or would cause
immediate, obvious, breakage. Either of which is fine.

On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:

> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:
> >>
> >> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
> >> <alex.hartmaier@gmail.com> wrote:
> >> >
> >> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
> >> >>
> >> >> > Can someone show an example, ideally on CPAN, where this gets used?
> >> >>
> >> >> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
> >> >>
> >> >>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> >> >>
> >> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
> >> >>
> >> >> if ( $] >= 5.006 && $] < 5.007003 ) {
> >> >> eval { $data = require 'unicode/Name.pl'; };
> >> >> }
> >> >> elsif ( $] >= 5.007003 ) {
> >> >> eval { $data = require 'unicore/Name.pl'; };
> >> >>
> >> >> # since v5.11.3, unicore/Name.pl creates subroutines
> >> >> # they end up in our namespace, so get rid of them
> >> >> undef *code_point_to_name_special;
> >> >> undef *name_to_code_point_special;
> >> >> }
> >> >>
> >> >> Guessing there may be other examples on CPAN – this is just the
> first one I found with grep.metacpan.org.
> >> >>
> >> >> Neil
> >> >>
> >> >
> >> >
> >> > Thanks for the grep.metacpan.org link, haven't thought about it for
> finding examples. I've looked at some others and using the return value of
> a require call is used quite frequently. So option 3 isn't a good one in my
> opinion, as a module changed to use the feature, most probably with 'use
> v5.38;' not thinking about the enabled feature, which would lead to another
> module failing because of the changed behavior.
> >>
> >> Anything relying on the return value of require as being anything
> >> other than true is already broken. The second time require is called
> >> for a module, it will turn true, not whatever the module tried to
> >> return. unicode/Name.pl is meant to be loaded via do, not require, in
> >> addition to being internal only.
> >>
> >> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
> >> its tests on, it still fails if you cause Name.pl to be loaded early.
> >>
> >> $ perl -e'use strict; use warnings; use charnames qw(greek); use
> >> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
> >> die "no names!" if !$meta->name;'
> >> no names! at -e line 1.
> >>
> >> I'd say it's better to cause these things to always fail, rather than
> >> allowing them to sometimes appear to work.
> >
> >
> > Look at some of the other modules using the return value of require from
> the grep.metacpan.org link.
>
> Do you have a concrete example?
>
> I've just removed the dist filter from Neils query, added *.pm to get rid
of the dist.ini matches and looked at some modules:
https://grep.metacpan.org/search?q=%3D+require&qd=&qft=*.pm

For example https://metacpan.org/dist/DT/source/lib/DT.pm#L49 and
https://metacpan.org/dist/File-FindLib/source/FindLib.pm#L55 are examples
I'd pick as reference.


> For most cases I saw, changing the module or file to always return
> true (as in !!1) would either not make any difference, or would cause
> immediate, obvious, breakage. Either of which is fine.
>

On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>>
>> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:
>> >>
>> >> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
>> >> <alex.hartmaier@gmail.com> wrote:
>> >> >
>> >> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
>> >> >>
>> >> >> > Can someone show an example, ideally on CPAN, where this gets used?
>> >> >>
>> >> >> I _think_ you were asking for an example of someone using the return value from a require. In which case:
>> >> >>
>> >> >> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>> >> >>
>> >> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>> >> >>
>> >> >> if ( $] >= 5.006 && $] < 5.007003 ) {
>> >> >> eval { $data = require 'unicode/Name.pl'; };
>> >> >> }
>> >> >> elsif ( $] >= 5.007003 ) {
>> >> >> eval { $data = require 'unicore/Name.pl'; };
>> >> >>
>> >> >> # since v5.11.3, unicore/Name.pl creates subroutines
>> >> >> # they end up in our namespace, so get rid of them
>> >> >> undef *code_point_to_name_special;
>> >> >> undef *name_to_code_point_special;
>> >> >> }
>> >> >>
>> >> >> Guessing there may be other examples on CPAN – this is just the first one I found with grep.metacpan.org.
>> >> >>
>> >> >> Neil
>> >> >>
>> >> >
>> >> >
>> >> > Thanks for the grep.metacpan.org link, haven't thought about it for finding examples. I've looked at some others and using the return value of a require call is used quite frequently. So option 3 isn't a good one in my opinion, as a module changed to use the feature, most probably with 'use v5.38;' not thinking about the enabled feature, which would lead to another module failing because of the changed behavior.
>> >>
>> >> Anything relying on the return value of require as being anything
>> >> other than true is already broken. The second time require is called
>> >> for a module, it will turn true, not whatever the module tried to
>> >> return. unicode/Name.pl is meant to be loaded via do, not require, in
>> >> addition to being internal only.
>> >>
>> >> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
>> >> its tests on, it still fails if you cause Name.pl to be loaded early.
>> >>
>> >> $ perl -e'use strict; use warnings; use charnames qw(greek); use
>> >> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
>> >> die "no names!" if !$meta->name;'
>> >> no names! at -e line 1.
>> >>
>> >> I'd say it's better to cause these things to always fail, rather than
>> >> allowing them to sometimes appear to work.
>> >
>> >
>> > Look at some of the other modules using the return value of require from the grep.metacpan.org link.
>>
>> Do you have a concrete example?
>>
> I've just removed the dist filter from Neils query, added *.pm to get rid of the dist.ini matches and looked at some modules: https://grep.metacpan.org/search?q=%3D+require&qd=&qft=*.pm
>
> For example https://metacpan.org/dist/DT/source/lib/DT.pm#L49

This only cares that require returns a true value, and avoids calling
return again in the future if so.

> and https://metacpan.org/dist/File-FindLib/source/FindLib.pm#L55 are examples I'd pick as reference.

This just passes the value on, doing nothing with it. There are no
users of File::FindLib on CPAN that use that return value.

Neither of these would be impacted by changing the return value to be
a simple true value.

>
>>
>> For most cases I saw, changing the module or file to always return
>> true (as in !!1) would either not make any difference, or would cause
>> immediate, obvious, breakage. Either of which is fine.

Op 14-06-2022 om 18:13 schreef Graham Knop:
> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
>>
>> For example https://metacpan.org/dist/DT/source/lib/DT.pm#L49
> This only cares that require returns a true value, and avoids calling
> return again in the future if so.


Nitpick, 'require' always returns a truthy value, otherwise it dies. So
this is just a cute shorthand for 'require DateTime::Format::Pg;
$HAVE_PG=1'.


HTH,

M4

On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:

> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
> >>
> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
> >> <alex.hartmaier@gmail.com> wrote:
> >> > Look at some of the other modules using the return value of require
> from the grep.metacpan.org link.
> >>
> >> Do you have a concrete example?
>

There are plenty of cases which are effectively "`require` is used instead
of `do`", i.e. calling `require` and the subsequent code relies on the
data, rather than truth of the return value.

Some examples from just the first page of results - there are others on
that page:

https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda

my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
my $func = AWS::Lambda::PSGI->wrap($app);

https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice

my $config = {};
if (-e $self->fullpath) {
$config = require $self->fullpath;

https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart

my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;

All of these are somewhat fragile: call the code twice or have something
else `require` the relevant module/file first, and they'd have problems.
However, given how often this pattern appears,
require-returns-`builtin::true` may be too disruptive if strictly enforced?

Keeping the original value _also_ doesn't seem like a good idea, `package
Example; my $should_drop_out_of_scope = ...;` for example.

On Tue, Jun 14, 2022 at 7:10 PM Tom Molesworth <tom@deriv.com> wrote:
>
> On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:
>>
>> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>> >>
>> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>> >> <alex.hartmaier@gmail.com> wrote:
>> >> > Look at some of the other modules using the return value of require from the grep.metacpan.org link.
>> >>
>> >> Do you have a concrete example?
>
>
> There are plenty of cases which are effectively "`require` is used instead of `do`", i.e. calling `require` and the subsequent code relies on the data, rather than truth of the return value.
>
> Some examples from just the first page of results - there are others on that page:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda
>
> my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
> my $func = AWS::Lambda::PSGI->wrap($app);
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice
>
> my $config = {};
> if (-e $self->fullpath) {
> $config = require $self->fullpath;
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart
>
> my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;
>
> All of these are somewhat fragile: call the code twice or have something else `require` the relevant module/file first, and they'd have problems. However, given how often this pattern appears, require-returns-`builtin::true` may be too disruptive if strictly enforced?

It would not be strictly enforced. It would only happen if the file
being required did `use v5.40;` or such a declaration. Most of these
cases would likely never add that declaration, and new code that did
would not be able to be used in this fragile way. If someone did add
such a declaration to their existing code, it would cause these uses
to immediately fail, which I see as an acceptable outcome.

>
> Keeping the original value _also_ doesn't seem like a good idea, `package Example; my $should_drop_out_of_scope = ...;` for example.
>

On Tue, Jun 14, 2022 at 7:10 PM Tom Molesworth <tom@deriv.com> wrote:

> On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:
>
>> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>> >>
>> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>> >> <alex.hartmaier@gmail.com> wrote:
>> >> > Look at some of the other modules using the return value of require
>> from the grep.metacpan.org link.
>> >>
>> >> Do you have a concrete example?
>>
>
> There are plenty of cases which are effectively "`require` is used instead
> of `do`", i.e. calling `require` and the subsequent code relies on the
> data, rather than truth of the return value.
>
> Some examples from just the first page of results - there are others on
> that page:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda
>
> my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
> my $func = AWS::Lambda::PSGI->wrap($app);
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice
>
> my $config = {};
> if (-e $self->fullpath) {
> $config = require $self->fullpath;
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart
>
> my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;
>
> All of these are somewhat fragile: call the code twice or have something
> else `require` the relevant module/file first, and they'd have problems.
> However, given how often this pattern appears,
> require-returns-`builtin::true` may be too disruptive if strictly enforced?
>
> Keeping the original value _also_ doesn't seem like a good idea, `package
> Example; my $should_drop_out_of_scope = ...;` for example.
>
> I saw those but they confused me.
So require just returns what the loaded file returns? So in case the file
ends in 1;, the return value is 1, but some return a blessed object and
this is returned?

Is that a feature or a misuse of 'require'?

2022-6-15 16:21 Alexander Hartmaier <alex.hartmaier@gmail.com> wrote:

> On Tue, Jun 14, 2022 at 7:10 PM Tom Molesworth <tom@deriv.com> wrote:
>
>> On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:
>>
>>> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
>>> <alex.hartmaier@gmail.com> wrote:
>>> >
>>> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>>> >>
>>> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>>> >> <alex.hartmaier@gmail.com> wrote:
>>> >> > Look at some of the other modules using the return value of require
>>> from the grep.metacpan.org link.
>>> >>
>>> >> Do you have a concrete example?
>>>
>>
>> There are plenty of cases which are effectively "`require` is used
>> instead of `do`", i.e. calling `require` and the subsequent code relies on
>> the data, rather than truth of the return value.
>>
>> Some examples from just the first page of results - there are others on
>> that page:
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda
>>
>> my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
>> my $func = AWS::Lambda::PSGI->wrap($app);
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice
>>
>> my $config = {};
>> if (-e $self->fullpath) {
>> $config = require $self->fullpath;
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart
>>
>> my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;
>>
>> All of these are somewhat fragile: call the code twice or have something
>> else `require` the relevant module/file first, and they'd have problems.
>> However, given how often this pattern appears,
>> require-returns-`builtin::true` may be too disruptive if strictly enforced?
>>
>> Keeping the original value _also_ doesn't seem like a good idea, `package
>> Example; my $should_drop_out_of_scope = ...;` for example.
>>
>> I saw those but they confused me.
> So require just returns what the loaded file returns? So in case the file
> ends in 1;, the return value is 1, but some return a blessed object and
> this is returned?
>
> Is that a feature or a misuse of 'require'?
>

I also want to know either of the following.

1. "require" ignores the return value of the .pm file to check whether it
is successful, and "require" returns builtin::true.

2. "require" ignores the return value of the .pm file to check whether it
is successful, and "require" returns the return value of the .pm file.

On Mon, Jun 06, 2022 at 11:05:59PM +0100, Neil Bowers wrote:
> This is a retrospective Pre-RFC for a proposal from Curtis, for which he submitted a draft RFC[1]. We nearly missed it when reviewing proposals in-flight in our PSC meeting last week, and decided to trigger a discussion here, to reinforce the process.
>
> Beginning and casual Perl programmers regularly get confused / caught out by the requirement to add `1;` at the end of their modules. To add to their confusion, there are plenty of modules on CPAN with humorous alternatives for "1".
>
> Curtis proposed a feature called something like yield_true, which would result in the current file yielding a true value on successful compilation. So a module could then look like this:
>
> package Zork;
> use feature 'yield_true';
>
> # code
>
> This is not a feature we’d expect people to use explicitly, but would be part of the version bundle, so you’d get it for free with a future `use v5.XY`.

Thinking about implementation, how should this behave if the included file was:

package Zork {
use feature 'yield_true';
}

remembering features (and use vX.XX) are lexical.

Or perhaps less reasonably:

package Zork;
{
{
{
use feature 'yield_true';
}
}
}

The true module on CPAN works by checking the filename between when
"true"->import() is called and when the check function for the
leaveeval is called, which a #line directive might break.

Tony

On Thu, 16 Jun 2022 at 12:29, Tony Cook <tony@develop-help.com> wrote:

> Thinking about implementation, how should this behave if the included file
> was:
>
> package Zork {
> use feature 'yield_true';
> }
>

Since it's called `yield_true` rather than `ignore_false`, I'd expect that
lexical scope to behave as if it was wrapped in `(...) or builtin::true`,
so the `require Zork;` would work as if it had been `package Zork;
builtin::true`. Similarly for nested scopes: behaving a bit like `perl
-le'print do { { { (undef) or 1 } } }'` with the true value propagating.
Presumably that would enforce scalar context: is that likely to be a
problem?

Similarly:

my $value = do { use feature 'yield_true'; undef }; # we're expecting
$value = builtin::true, yes?

This level of detail seems more appropriate for the RFC stage. Seems
there's enough interest to go beyond pre-RFC here?

Porters,

Here's what I think, on the matter of eliminating that pesky magic true value.

In "Foo.pm" we want a way to signal that when require-d, it is treated as if it had evaluated to true, even if (say) the last statement is "0;".

The biggest question, for me, is how we signal that. The mostly-undebated option here has been:
use feature 'xyzzy'; # for some value of "xyzzy"

The problem with that is that "use feature" is always lexical, but it's not clear that this makes sense lexically.
require v5.40.0; # assert version number is high enough but do not enable features

do_some_stuff;

package Foo {
use v5.40.0;
# strict is on
}

# strict is off again

more_code_here;

0;

# EOF

If the yield-true feature exists and is enabled by v5.40, what should happen here? If it's treated as if on, we're violating the expectation of lexical effect. If it's treated as off, we've created a new kind of feature that only matters at top-level scope in a file. If a programmer has written all their code inside a "package NAME BLOCK" structure, which previously would have no particular problem, they now don't fully benefit from "use vX".

All of this *makes sense*, but a large part of getting rid of the need for the "magic true value" is to avoid confusing programmers who don't want to think about the weird under-the-hood stuff here. I don't think we're avoiding enough confusion. The error "Foo.pm did not return a true value." could be worse, but it's not the best, either.

Issuing a "use vX doesn't make sense at non-top-level" also seems unappealing.

I don't have a great solution to offer. So far what I've got is:
* if "require" errors because of a false value
* and the file required did enable the feature
* but did not *explicitly* disable it, subsequently
* *then*, a warning is issued "File.pm did not return a true value. The xyzzy feature, which would eliminate this error, was enabled at line 123 but only in a limited lexical scope, ending at line 321."
I'm not in love with it.

--
rjbs

I was having similar thoughts to what Ricardo said here, back when this thread
was started.

My thought was that if the feature in discussion was being treated consistently,
then it would necessarily have to affect a lot more things.

How I interpret Perl's current behavior is that we have a general feature such
that in any lexical context, meaning a block defined by a pair of curly braces
as well as the base scope of each file, users have the choice of having explicit
return statements or having implicit return statements. In each scope, an
explicit "return" means that is the result value from executing the block/file,
and otherwise if the last statement executed in a scope isn't a "return", then
the result is implicitly what the last statement returns.

So in this context, I interpret a generalization of "yield true" to behave as if
every lexical scope or block or file has an implicit "return true;" added to the
end of it.

So when "yield true" is in effect, every block will return true instead of the
result of the last statement, unless the last statement is a "return" statement.
And even then, logically it still works as if the implicit statement is
present, but its just never executed because the explicit "return" ends the
block before its reached.

In that case, "yield true" absolutely makes sense as a lexical scope, where one
can then turn it on or off between nested scopes.

But then the question is, how much code would this break, that is relying on
implicit returns in blocks. My thought is, it would break a lot, at least in
the case of blocks used within expressions like map/grep/sort/do/etc.

So, I have an alternate proposal:

1. Treat the "yield true" feature like how we treat explicit declarations of
file encoding, in that they are explicitly NOT lexical, and that having one
anywhere in a file causes it to apply to the entire file, and/or it is only
legal for the declaration to exist at the top level of a file and not inside any
block.

2. The above-mentioned version of "yield true" is included automatically when
one says "use v5.38;" and above, meaning the only legal thing one can actually
do is optionally say "no yield_true;" (or they can still say "use yield_true;"
but it would be redundant, unless this is also provided as a CPAN module for use
with older Perls).

3. The "yield true" feature only has any effect on the top-level lexical scope
of a file, meaning what is outside of all curly brace blocks.

4. We also add the ability, if it isn't already allowed, one to use explicit
"return" statements at the top level of a file. This empowers people to
explicitly say that a file returns an explicit value which could be anything
true or false. If that exists, one can say "use 5.38;" WITHOUT having to
explicitly turn off yield_true in order to yield something else, because any
return statement at the top level would override any yield_true that may be in
effect, because the implicit "return true;" at file's end isn't reached.

What are thoughts on this?

-- Darren Duncan

On 2022-06-17 5:00 p.m., Ricardo Signes wrote:
> Porters,
>
> Here's what I think, on the matter of eliminating that pesky magic true value.
>
> In "Foo.pm" we want a way to signal that when require-d, it is treated as if it
> had evaluated to true, even if (say) the last statement is "0;".
>
> The biggest question, for me, is how we signal that.  The mostly-undebated
> option here has been:
>
> use feature 'xyzzy'; # for some value of "xyzzy"
>
>
> The problem with that is that "use feature" is always lexical, but it's not
> clear that this makes sense lexically.
>
> require v5.40.0; # assert version number is high enough but do not enable features
>
> do_some_stuff;
>
> package Foo {
> use v5.40.0;
> # strict is on
> }
>
> # strict is off again
>
> more_code_here;
>
> 0;
>
> # EOF
>
>
> If the yield-true feature exists and is enabled by v5.40, what should happen
> here?  If it's treated as if on, we're violating the expectation of lexical
> effect.  If it's treated as off, we've created a new kind of feature that only
> matters at top-level scope in a file.  If a programmer has written all their
> code inside a "package NAME BLOCK" structure, which previously would have no
> particular problem, they now don't fully benefit from "use vX".
>
> All of this /makes sense/, but a large part of getting rid of the need for the
> "magic true value" is to avoid confusing programmers who don't want to think
> about the weird under-the-hood stuff here.  I don't think we're avoiding enough
> confusion.  The error "Foo.pm did not return a true value." could be worse, but
> it's not the best, either.
>
> Issuing a "use vX doesn't make sense at non-top-level" also seems unappealing.
>
> I don't have a great solution to offer.  So far what I've got is:
>
> * if "require" errors because of a false value
> * and the file required did enable the feature
> * but did not /explicitly/ disable it, subsequently
> * /then/, a warning is issued "File.pm did not return a true value.  The xyzzy
> feature, which would eliminate this error, was enabled at line 123 but only
> in a limited lexical scope, ending at line 321."
>
> I'm not in love with it.
>
> --
> rjbs
>

On Fri, Jun 17, 2022, at 23:00, Darren Duncan wrote:
> 1. Treat the "yield true" feature like how we treat explicit declarations of
> file encoding, in that they are explicitly NOT lexical, and that having one
> anywhere in a file causes it to apply to the entire file, and/or it is only
> legal for the declaration to exist at the top level of a file and not inside any
> block.

What are you referring to when you say "how we treat explicit declarations of file encoding"?

> 4. We also add the ability, if it isn't already allowed, one to use explicit
> "return" statements at the top level of a file.

This already exists as can be trivially verified:
$ echo 1 > foo.pm
$ echo "return 0; 1" > bar.pm
$ perl -I . -Mfoo -e0
$ perl -I . -Mbar -e0
bar.pm did not return a true value.
BEGIN failed--compilation aborted.

--
rjbs

On 2022-06-17 8:10 p.m., Ricardo Signes wrote:
> On Fri, Jun 17, 2022, at 23:00, Darren Duncan wrote:
>> 1.  Treat the "yield true" feature like how we treat explicit declarations of
>> file encoding, in that they are explicitly NOT lexical, and that having one
>> anywhere in a file causes it to apply to the entire file, and/or it is only
>> legal for the declaration to exist at the top level of a file and not inside any
>> block.
>
> What are you referring to when you say "how we treat explicit declarations of
> file encoding"?

I refer to when we say "use utf8;" or "use encoding" etc.

I know there have been other discussions about improving the behavior of this,
but one key takeaway I had was that in practice it didn't really seem to be a
good idea to support a file that was partly one encoding and partly another, and
so best practice would be that any declarations like "use utf8" etc should
necessarily be referring to the whole file and not a lesser lexical scope.

So I'm saying that "yield_true" should be the same in the sense that while
logically it COULD be lexical, there's in practice no good reason for it to be
so, or if there was, it would be a very different feature than one designed to
just remove the need for a "1;", that different feature would be mainly about
altering how subroutines behave.

-- Darren Duncan

Hi there,

On Fri, 17 Jun 2022, Darren Duncan wrote:

> ...
> What are thoughts on this?

So far it seems like a case of out of the frying pan and into the fire.

--

73,
Ged.

On Fri, Jun 17, 2022, at 23:44, Darren Duncan wrote:
> On 2022-06-17 8:10 p.m., Ricardo Signes wrote:
> > On Fri, Jun 17, 2022, at 23:00, Darren Duncan wrote:
> >> 1. Treat the "yield true" feature like how we treat explicit declarations of
> >> file encoding, in that they are explicitly NOT lexical, and that having one
> >> anywhere in a file causes it to apply to the entire file, and/or it is only
> >> legal for the declaration to exist at the top level of a file and not inside any
> >> block.
> >
> > What are you referring to when you say "how we treat explicit declarations of
> > file encoding"?
>
> I refer to when we say "use utf8;" or "use encoding" etc.

Then you are mistaken, because "use utf8" is lexically scoped.
dinah:~$ cat length
use v5.36.0;

my $str1 = do { use utf8; "????" };
my $str2 = do { "????" };

say length $str1;
say length $str2;

dinah:~$ perl that-program-above
1
4

encoding.pm has been deprecated for nine years and fatal to use for seven. It's not a good thing to cite as example. But also, if you travel back in time and test it, its behavior is terrible and a good example for why "looks lexical, actually silently file-scoped" is a bad idea. It only affects the file *after it appears* in the file. This is one of the points we were going to pains to deal with when discussing source::encoding: how do you ensure whole-document coherency?

> So I'm saying that "yield_true" should be the same in the sense that while logically it COULD be lexical, there's in practice no good reason for it to be so, or if there was, it would be a very different feature than one designed to
> just remove the need for a "1;", that different feature would be mainly about altering how subroutines behave.

What am trying to do is not make it lexical, but to anticipate places where the user will be surprised and either make them not surprising or, at least, tell the user what happened.

--
rjbs

On Fri, Jun 17, 2022 at 08:00:10PM -0400, Ricardo Signes wrote:
> Porters,
>
> Here's what I think, on the matter of eliminating that pesky magic true value.

And here's what I think.

We should be guided by avoiding, as far as possible, edge/special cases,
a.k.a. the principle of least surprise.

So I propose:

1) that the yield_true feature is strictly lexically scoped. Because
otherwise it's a special case.

99.9% of the time it will be enabled at the top of the src file, so no one
will care much. In the rare case that someone does

{
use v5.40;
... something relying on 5.40 syntax ...
}
... normal perl ...
0;

then regardless whether their code makes much sense of not, it should do
as expected, and croak with "Foo.pm did not return a true value".

2) that, regardless of whether the require returns via an explicit
'return', or by implicitly falling off the end of the src file, whether
perl does the "croak if false" test is governed purely by whether
'yield_true' was in scope at the last statement executed. I.e. we don't
distinguish between implicit and explicit returns - again, otherwise it's
a special case.

If someone really wants the old behaviour under some circumstances, they
can do either:

die "I detected a problem while executing Foo.pm" if $bad;

or to more exactly reproduce the old behaviour,

use v5.40;
...

if ($bad) {
no feature 'yield_true';
return 0;
}



--
A power surge on the Bridge is rapidly and correctly diagnosed as a faulty
capacitor by the highly-trained and competent engineering staff.
-- Things That Never Happen in "Star Trek" #9

On Sun, Jun 19, 2022 at 01:23:30PM +0100, Dave Mitchell wrote:
> And here's what I think.

and I forgot to mention this way is easy to implement too.

--
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
(with apologies to William Blake)

On 2022-06-19 5:46 a.m., Dave Mitchell wrote:
> On Sun, Jun 19, 2022 at 01:23:30PM +0100, Dave Mitchell wrote:
>> And here's what I think.
>
> and I forgot to mention this way is easy to implement too.

I like your proposal. -- Darren Duncan

On 2022-06-19 5:23 a.m., Dave Mitchell wrote:
> 1) that the yield_true feature is strictly lexically scoped. Because
> otherwise it's a special case.
>
> 99.9% of the time it will be enabled at the top of the src file, so no one
> will care much. In the rare case that someone does
>
> {
> use v5.40;
> ... something relying on 5.40 syntax ...
> }
> ... normal perl ...
> 0;
>
> then regardless whether their code makes much sense of not, it should do
> as expected, and croak with "Foo.pm did not return a true value".
>
> 2) that, regardless of whether the require returns via an explicit
> 'return', or by implicitly falling off the end of the src file, whether
> perl does the "croak if false" test is governed purely by whether
> 'yield_true' was in scope at the last statement executed. I.e. we don't
> distinguish between implicit and explicit returns - again, otherwise it's
> a special case.

So if yield_true is lexically scoped, what do we expect to happen here?

sub foo {
use v5.40;
0;
}

my $bar = foo();

print $bar;

So what does $bar contain? Does it contain zero or true?

If yield_true is lexically scoped, then we would expect executing the scope
containing it to return true, which in this case is the subroutine, right?

Likewise, what do we expect here?

use v5.40;

sub foo {
0;
}

my $bar = foo();

print $bar;

In either case, the body of subroutine too is in scope of the yield_true, so
what do we expect it to return?

-- Darren Duncan

It seems to me that if a lexically scoped yield_true isn't going to behave as I
indicated, affecting the results of subroutines as well, then I would say maybe
the feature is badly named.

Maybe it should be called something like require_treats_this_scope_as_yielding_true.

Then it is much more clear that we aren't actually changing the result value of
the block or file, that it remains as it was, but rather we are changing the
behaviour of require/etc to introspect the source file it is called on and
require/etc behaves differently if require_treats_this_scope_as_yielding_true is
present in some appropriate place.

Different naming makes it more clear if what we are actually changing is how
require/etc behave and NOT how the actual code being required behaves, meaning
its actual return values.

-- Darren Duncan

On 2022-06-19 5:57 p.m., Darren Duncan wrote:
> On 2022-06-19 5:23 a.m., Dave Mitchell wrote:
>> 1) that the yield_true feature is strictly lexically scoped. Because
>> otherwise it's a special case.
>>
>> 99.9% of the time it will be enabled at the top of the src file, so no one
>> will care much. In the rare case that someone does
>>
>>      {
>>          use v5.40;
>>          ... something relying on 5.40 syntax ...
>>      }
>>      ... normal perl ...
>>      0;
>>
>> then regardless whether their code makes much sense of not, it should do
>> as expected, and croak with "Foo.pm did not return a true value".
>>
>> 2) that, regardless of whether the require returns via an explicit
>> 'return', or by implicitly falling off the end of the src file, whether
>> perl does the "croak if false" test is governed purely by whether
>> 'yield_true' was in scope at the last statement executed. I.e. we don't
>> distinguish between implicit and explicit returns - again, otherwise it's
>> a special case.
>
> So if yield_true is lexically scoped, what do we expect to happen here?
>
>   sub foo {
>     use v5.40;
>     0;
>   }
>
>   my $bar = foo();
>
>   print $bar;
>
> So what does $bar contain?  Does it contain zero or true?
>
> If yield_true is lexically scoped, then we would expect executing the scope
> containing it to return true, which in this case is the subroutine, right?
>
> Likewise, what do we expect here?
>
>   use v5.40;
>
>   sub foo {
>     0;
>   }
>
>   my $bar = foo();
>
>   print $bar;
>
> In either case, the body of subroutine too is in scope of the yield_true, so
> what do we expect it to return?
>
> -- Darren Duncan

On Sun, Jun 19, 2022 at 06:06:00PM -0700, Darren Duncan wrote:
> It seems to me that if a lexically scoped yield_true isn't going to behave
> as I indicated, affecting the results of subroutines as well, then I would
> say maybe the feature is badly named.

I don't think anyone has proposed that.

I am proposing that, for the one specific case where perl has just exited
during execution of a require'd src file, then the special check it
currently does (on whether the return value is zero) should be skipped if
'yield_true' was in scope at the statement where the code returned
(or fell off the end).

The pragma will have no effect whatsoever on the return value of
functions.

--
Overhead, without any fuss, the stars were going out.
-- Arthur C Clarke

On Sun, 19 Jun 2022 13:23:30 +0100
Dave Mitchell <davem@iabyn.com> wrote:

> And here's what I think.
>
> We should be guided by avoiding, as far as possible, edge/special
> cases, a.k.a. the principle of least surprise.
>
> So I propose:
>
> 1) that the yield_true feature is strictly lexically scoped. Because
> otherwise it's a special case.
...

Yeah, I'm with Dave on this. Keeping it as a lexically-scoped one makes
the model simpler for users to understand, writers to document, and
porters to implement.

It already justworks with code written in this style:

package My::Package::Name;
use v5.40;

or

use v5.40;
package My::Package::Name;

I am willing to bet that >99% of perl files ever encountered are of one
of these two forms.

In the tiny cornercase that people use a toplevel brace structure for
their entire file; a.la.

package My::Package::Name {
use v5.40;
}

then maybe we just tell them "hey, don't do that. There's no need to".

That structure does also give people a real valid escape hatch in case
they genuinely did not want that feature.

Also I suspect this is the only way it'll work to not upset the "concat
all the .pm files into one script" fatpackers.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Mon, Jun 20, 2022 at 1:41 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Sun, 19 Jun 2022 13:23:30 +0100
>


> In the tiny cornercase that people use a toplevel brace structure for
> their entire file; a.la.
>
> package My::Package::Name {
> use v5.40;
> }
>
> then maybe we just tell them "hey, don't do that. There's no need to".
>
> That structure does also give people a real valid escape hatch in case
> they genuinely did not want that feature.
>

Uh oh. I do that quite a bit and more and more of my code examples are like
that. I like knowing that I have a proper lexical block there to
encapsulate things. To me, the fact that the following prints "3" is a
feature I prefer to avoid:

package Foo; my $x = 3;
package Bar; say $x;

If I switch those to postfix blocks, it won't compile.

Best,
Curtis "Ovid" Poe
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/

Op 21-06-2022 om 10:02 schreef Ovid:
> On Mon, Jun 20, 2022 at 1:41 PM Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>
> On Sun, 19 Jun 2022 13:23:30 +0100
>
> In the tiny cornercase that people use a toplevel brace structure for
> their entire file; a.la <http://a.la>.
>
>   package My::Package::Name {
>     use v5.40;
>   }
>
> then maybe we just tell them "hey, don't do that. There's no need to".
>
> That structure does also give people a real valid escape hatch in case
> they genuinely did not want that feature.
>
>
> Uh oh. I do that quite a bit and more and more of my code examples are
> like that. I like knowing that I have a proper lexical block there to
> encapsulate things. To me, the fact that the following prints "3" is a
> feature I prefer to avoid:
>
>     package Foo; my $x = 3;
>     package Bar; say $x;
>
> If I switch those to postfix blocks, it won't compile.


I may be missing something, but wouldn't


use v5.78;

package Foo {}

package Bar {}


Fix that? In fact, why would you do:


package Foo {

    use v5.34;

}

package Bar {

    use 5.36;

}

which is the only reason I can think of to put the use inside the
package declaration, if the versions would differ.


HTH,

M4

On Tue, Jun 21, 2022 at 11:22 AM Martijn Lievaart <m@rtij.nl> wrote:

> I may be missing something, but wouldn't
>
>
> use v5.78;
>
> package Foo {}
>
> package Bar {}
>
>
> Fix that? In fact, why would you do
>

Whelp. I'm an idiot. Thanks, Martijn :)

Best,
Curtis "Ovid" Poe
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/

Summary.

Are we going in the following direction?

If the "yield_true" feature is enabled,

- the effect is local-scope. Generally the "yield_true" feature is used
at the top level file scope.
- It has no effect on the return value of .pm file. Both an implicit
return value and an explicit return value specified by return statement.
- "require" ignores the return value to determine if the module was
successfully loaded.
- "require" returns the return value of .pm file just like the current
behavior.

Den 07.06.2022 06:59, skrev Tony Cook:
> On Tue, Jun 07, 2022 at 09:16:22AM +0900, Yuki Kimoto wrote:
>> 2022-6-7 7:07 Neil Bowers<neilb@neilb.org> wrote:
>>
>>> This is a retrospective Pre-RFC for a proposal from Curtis, for which he
>>> submitted a draft RFC[1]. We nearly missed it when reviewing proposals
>>> in-flight in our PSC meeting last week, and decided to trigger a discussion
>>> here, to reinforce the process.
>>>
>>> ...
>>>
>>> [1]https://github.com/Perl/RFCs/pull/16
>>>
>>>
>> I want to hear the haarg' proposal a little more.
>>
>>> There is another model that could be used. could always ignore the return
>> value from the file if the feature was enabled. This is simpler than the
>> previous option, but accomplishes essentially the same thing. It still
>> needs special handling in , but doesn't need to care about an implicit vs
>> explicit return. In practice, the return value from a ed file is not usable
>> for anything. The only impact it will have on perl's behavior is throwing
>> an error for a false value. This is better done by throwing a real error.
>> If there is no real purpose for returning an explicit value, why complicate
>> the model by trying to handle specially?
>>
>> Does this mean changing the behavior of "use", "require", "do" in the
>> "yield_true"
>> feature?
> There would be no change for "do", it doesn't require truthiness.
>
> Simply removing the requirement is close to trivial (below), but I'd
> expect it to break some downstream tests. It breaks a small number of
> tests in core, including one for parent.pm.
>
> Tony
>
<diff of perl5 changes needed>

Seeing how the lexical/global etc discussions are going with
clarifications needed even among savvy perl hackers – I wonder – why
this particular route (ignore return value (and croak if file is not
found or not compiled)) under a new version isn't the best route?

I think the test in parent.pm seems to be testing that parent.pm dies if
the included file returned false.

I believe `require` is often wrapped in eval and saves its state so you
can't run execute the module several times (easily) and for general
dynamical modules people tend to use Module::Load or similar?

As for do, it might not require truthiness in itself, but a user might
rely on the return value when using it in like in the `perldoc -f do`
examples:

  # Read in config files: system first, then user.
  # Beware of using relative pathnames here.
  for $file ("/share/prog/defaults.rc",
     "$ENV{HOME}/.someprogrc")
  {
     unless ($return = do $file) {
     warn "couldn't parse $file: $@" if $@;
     warn "couldn't do $file: $!" unless defined $return;
     warn "couldn't run $file" unless $return;
   }
}

but I guess it still wouldn't need any change per se.

Are there examples of people utilizing the last/return value of a
included file to state an error in CPAN or in the wild?

--

Nicolas Mendoza

Op 22-06-2022 om 03:55 schreef Nicolas Mendoza:
>
> Are there examples of people utilizing the last/return value of a
> included file to state an error in CPAN or in the wild?
>
>

I use this to load specific implementations of generic subs. By do-ing a
specific file which returns the sub, I load a reference to the correct
implementation for this run.


HTH,

M4

On Wed, Jun 22, 2022 at 2:00 AM Martijn Lievaart <m@rtij.nl> wrote:

> Op 22-06-2022 om 03:55 schreef Nicolas Mendoza:
>
> Are there examples of people utilizing the last/return value of a included
> file to state an error in CPAN or in the wild?
>
>
> I use this to load specific implementations of generic subs. By do-ing a
> specific file which returns the sub, I load a reference to the correct
> implementation for this run.
>

The behavior of "do" is not affected by what's being discussed here.

-Dan

2022-6-22 15:29 Dan Book <grinnz@gmail.com> wrote:

> On Wed, Jun 22, 2022 at 2:00 AM Martijn Lievaart <m@rtij.nl> wrote:
>
>> Op 22-06-2022 om 03:55 schreef Nicolas Mendoza:
>>
>> Are there examples of people utilizing the last/return value of a
>> included file to state an error in CPAN or in the wild?
>>
>>
>> I use this to load specific implementations of generic subs. By do-ing a
>> specific file which returns the sub, I load a reference to the correct
>> implementation for this run.
>>
>
> The behavior of "do" is not affected by what's being discussed here.
>
> -Dan
>

There seems to be a lot of misunderstanding and confusion due to the
feature name ”yeald_true” and the reference implementation "true.xs".

I think the correct feature name is a shortened name for "require ignores
the return value of the module file to check if the module was loaded
successfully".

On 2022-06-21 11:43 p.m., Yuki Kimoto wrote:
> There seems to be a lot of misunderstanding and confusion due to the feature
> name ”yeald_true” and the reference implementation "true.xs".
>
> I think the correct feature name is a shortened name for "require ignores the
> return value of the module file to check if the module was loaded successfully".

I will repeat (reworded) something I said before, which is that I feel this
feature should be renamed, as yield_true is clearly and repeatedly giving people
the wrong idea for what it does, and the feature would be good to be renamed to
something that more accurately describes what it does. Or if that isn't
renamed, at least the documentation will have to be very clear to explain the
real behavior and not what other behaviors the name would seem to imply. --
Darren Duncan

2022-6-22 16:12 Darren Duncan <darren@darrenduncan.net> wrote:

> On 2022-06-21 11:43 p.m., Yuki Kimoto wrote:
> > There seems to be a lot of misunderstanding and confusion due to the
> feature
> > name ”yeald_true” and the reference implementation "true.xs".
> >
> > I think the correct feature name is a shortened name for "require
> ignores the
> > return value of the module file to check if the module was loaded
> successfully".
>
> I will repeat (reworded) something I said before, which is that I feel
> this
> feature should be renamed, as yield_true is clearly and repeatedly giving
> people
> the wrong idea for what it does, and the feature would be good to be
> renamed to
> something that more accurately describes what it does. Or if that isn't
> renamed, at least the documentation will have to be very clear to explain
> the
> real behavior and not what other behaviors the name would seem to imply.
> --
> Darren Duncan
>

I agree.

Op 22-06-2022 om 08:29 schreef Dan Book:
> On Wed, Jun 22, 2022 at 2:00 AM Martijn Lievaart <m@rtij.nl> wrote:
>
> Op 22-06-2022 om 03:55 schreef Nicolas Mendoza:
>>
>> Are there examples of people utilizing the last/return value of a
>> included file to state an error in CPAN or in the wild?
>>
>>
>
> I use this to load specific implementations of generic subs. By
> do-ing a specific file which returns the sub, I load a reference
> to the correct implementation for this run.
>
>
> The behavior of "do" is not affected by what's being discussed here.
>

I'm not sure it isn't, although I agree it shouldn't. And I think
consensus is emerging it shouldn't.


HTH,

M4

On Wed, 22 Jun 2022 00:12:30 -0700
Darren Duncan <darren@darrenduncan.net> wrote:

> On 2022-06-21 11:43 p.m., Yuki Kimoto wrote:
> > There seems to be a lot of misunderstanding and confusion due to
> > the feature name ”yeald_true” and the reference implementation
> > "true.xs".
> >
> > I think the correct feature name is a shortened name for "require
> > ignores the return value of the module file to check if the module
> > was loaded successfully".
>
> I will repeat (reworded) something I said before, which is that I
> feel this feature should be renamed, as yield_true is clearly and
> repeatedly giving people the wrong idea for what it does

Back in the very beginning I first mentioned the name "yield_true", and
I said:

> On those latter two points: I could imagine that use v7 enables some
> features to get those. Lets call them for sake of argument
>
> use feature qw( export_attr yield_true )

-- https://github.com/Perl/RFCs/pull/11#issuecomment-1022388554

I probably should have made clearer, that was just a 5-second thought
of a name. I don't think it's a very good name, I just made it up for
the comment to close that PR.

It is verymuch still in need of a better name :)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, Jun 22, 2022 at 1:19 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> Summary.
>
> Are we going in the following direction?
>
> If the "yield_true" feature is enabled,
>
> - the effect is local-scope. Generally the "yield_true" feature is used
> at the top level file scope.
> - It has no effect on the return value of .pm file. Both an implicit
> return value and an explicit return value specified by return statement.
> - "require" ignores the return value to determine if the module was
> successfully loaded.
> - "require" returns the return value of .pm file just like the current
> behavior.
>
> Thanks for the summary!
So point 3 is what should be changed, 1 is an implementation detail and the
other two are just how require already works?

'require' currently checks the return value and throws an exception if it's
false in boolean context. This check should be disabled by the feature.

Correct?

On Wed, Jun 22, 2022 at 1:19 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
> Summary.
>
> Are we going in the following direction?
>
> If the "yield_true" feature is enabled,
>
> - the effect is local-scope. Generally the "yield_true" feature is used at the top level file scope.
> - It has no effect on the return value of .pm file. Both an implicit return value and an explicit return value specified by return statement.
> - "require" ignores the return value to determine if the module was successfully loaded.
> - "require" returns the return value of .pm file just like the current behavior.
>

I think having require return the last value from the file would be a
terrible change.

Currently, require will always return a true value, because anything
else will croak. There is plenty of code that relies on this. For
example:

if (eval { require $module }) { ... }

This has always been a reliable way to check if the module could be
loaded. If require continues to return the (possibly false) value from
the file, plenty of code will break. In fact, using the return value
of require as a true value has been the only reliable use of its
return value, since it will not return the "last value" after the
first call to require for a given file.

I strongly believe that when require loads a file that is using this
feature, it should ignore the final value from the module and instead
return a standard boolean true.

On Fri, 24 Jun 2022 at 04:52, Graham Knop <haarg@haarg.org> wrote:

> On Wed, Jun 22, 2022 at 1:19 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
> >
> > Summary.
> >
> > Are we going in the following direction?
> >
> > If the "yield_true" feature is enabled,
> >
> > - the effect is local-scope. Generally the "yield_true" feature is
> used at the top level file scope.
> > - It has no effect on the return value of .pm file. Both an implicit
> return value and an explicit return value specified by return statement.
> > - "require" ignores the return value to determine if the module was
> successfully loaded.
> > - "require" returns the return value of .pm file just like the current
> behavior.
> >
>
> I think having require return the last value from the file would be a
> terrible change.
>

It already returns the last value _if it was true_, so I think this
description is a bit misleading - the concern here could be reworded as
"require should never return false", since that'd be what breaks the eval {
require } combination?

Again, I think this is long past any reasonable "pre-RFC" stage, and it'd
make more sense to continue the discussion based on a real RFC, but:

- `perldoc -f require` includes a Perl implementation of (most of) the
require() functionality
- that seems like a good starting point to summarise the proposed change as
hopefully-unambiguous code

Would this be accurate, for example:

use Carp 'croak';
use version;

sub require {
my ($filename) = @_;
if ( my $version = eval { version->parse($filename) } )
{
if ( $version > $^V ) {
my $vn = $version->normal;
croak "Perl $vn required--this is only $^V,
stopped";
}
return 1;
}

if (exists $INC{$filename}) {
return 1 if $INC{$filename};
croak "Compilation failed in require";
}

foreach $prefix (@INC) {
if (ref($prefix)) {
#... do other stuff - see text below ....
}
# (see text below about possible appending of .pmc
# suffix to $filename)
my $realfilename = "$prefix/$filename";
next if ! -e $realfilename || -d _ || -b _;
$INC{$filename} = $realfilename;
my $result = do($realfilename);
# but run in caller's namespace

if (!defined $result) {
$INC{$filename} = undef;
croak $@ ? "$@Compilation failed in require"
: "Can't locate $filename: $!\n";
}
- if (!$result) {
+ if (!$result and
!$^H{require_without_throwing_exceptions_when_false_feature_formerly_described_as_yield_true})
{
delete $INC{$filename};
croak "$filename did not return true value";
}
+ $result ||= builtin::true;
$! = 0;
return $result;
}
croak "Can't locate $filename in \@INC ...";
}

On Thu, Jun 23, 2022 at 5:10 PM Tom Molesworth via perl5-porters <
perl5-porters@perl.org> wrote:

> On Fri, 24 Jun 2022 at 04:52, Graham Knop <haarg@haarg.org> wrote:
>
>> On Wed, Jun 22, 2022 at 1:19 AM Yuki Kimoto <kimoto.yuki@gmail.com>
>> wrote:
>> >
>> > Summary.
>> >
>> > Are we going in the following direction?
>> >
>> > If the "yield_true" feature is enabled,
>> >
>> > - the effect is local-scope. Generally the "yield_true" feature is
>> used at the top level file scope.
>> > - It has no effect on the return value of .pm file. Both an implicit
>> return value and an explicit return value specified by return statement.
>> > - "require" ignores the return value to determine if the module was
>> successfully loaded.
>> > - "require" returns the return value of .pm file just like the
>> current behavior.
>> >
>>
>> I think having require return the last value from the file would be a
>> terrible change.
>>
>
> It already returns the last value _if it was true_, so I think this
> description is a bit misleading - the concern here could be reworded as
> "require should never return false", since that'd be what breaks the eval {
> require } combination?
>

Not completely true anyway; it only returns the last value if the module
has not previously been successfully loaded. So anything relying on it
being anything other than a generic true value should be encouraged to fix
their code.

-Dan

On Thu, Jun 23, 2022 at 2:21 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

>
> Back in the very beginning I first mentioned the name "yield_true", and
> I said:
>
> > On those latter two points: I could imagine that use v7 enables some
> > features to get those. Lets call them for sake of argument
> >
> > use feature qw( export_attr yield_true )
>
> -- https://github.com/Perl/RFCs/pull/11#issuecomment-1022388554
>
> I probably should have made clearer, that was just a 5-second thought
> of a name. I don't think it's a very good name, I just made it up for
> the comment to close that PR.
>
> It is verymuch still in need of a better name :)
>
> --
> Paul "LeoNerd" Evans
>
>
Could I suggest 'module_requires_true' as the name? Since it's not actually
intended to be used directly, we could just have it as a default "no"
feature, like indirect. So you know that no module requires true at the
end.

2022-6-24 5:52 Graham Knop <haarg@haarg.org> wrote:

> On Wed, Jun 22, 2022 at 1:19 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
> >
> > Summary.
> >
> > Are we going in the following direction?
> >
> > If the "yield_true" feature is enabled,
> >
> > - the effect is local-scope. Generally the "yield_true" feature is
> used at the top level file scope.
> > - It has no effect on the return value of .pm file. Both an implicit
> return value and an explicit return value specified by return statement.
> > - "require" ignores the return value to determine if the module was
> successfully loaded.
> > - "require" returns the return value of .pm file just like the current
> behavior.
> >
>
> I think having require return the last value from the file would be a
> terrible change.
>
> Currently, require will always return a true value, because anything
> else will croak. There is plenty of code that relies on this. For
> example:
>
> if (eval { require $module }) { ... }
>
> This has always been a reliable way to check if the module could be
> loaded. If require continues to return the (possibly false) value from
> the file, plenty of code will break. In fact, using the return value
> of require as a true value has been the only reliable use of its
> return value, since it will not return the "last value" after the
> first call to require for a given file.
>
> I strongly believe that when require loads a file that is using this
> feature, it should ignore the final value from the module and instead
> return a standard boolean true.
>

Summary again.

- the effect is local-scope. Generally the "yield_true" feature is used at
the top level file scope.
- It has no effect on the return value of .pm file. Both an implicit return
value and an explicit return value specified by return statement.
- "require" ignores the return value to determine if the module was
successfully loaded.
- "require" always returns true value except when the exceptions are thrown
differently from the current behavior. (Changed)

Current behavior of require:

# Foo.pm
package Foo;

"ABC";

# main.pl
use strict;
use warnings;
use FindBin;
use lib "$FindBin::Bin";

my $ret = require Foo;

# ABC
warn $ret;

my $ret2 = require Foo;

# 1
warn $ret2;

On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote:
> On Fri, Jun 17, 2022 at 08:00:10PM -0400, Ricardo Signes wrote:
> > Porters,
> >
> > Here's what I think, on the matter of eliminating that pesky magic true value.
>
> And here's what I think.

I think you and I are in agreement, except for one small matter: I think that it'd be useful to say "module evaluated to false, despite having at some point enabled yield true, which probably indicates a mistake." If this ends up being onerous, I think it's something we can do without. But I think it will help users who do what Ovid mentioned doing: writing all their code in a block. The feature under discussion is the only one that would really be affected by writing your code that way. That's why I think it's plausible it's happening.

Why don't we start with just implementing the basic feature and then we have a year to think more about the warning if we want. ????

Also, we know it needs a name. I suggest 'module_true'. If the feature is on, then this module will be treated as evaluating true. I don't want to say 'require_ignores_false' or something because that could imply it changes the behavior of "require" in this scope.

--
rjbs

On Fri, Jun 24, 2022 at 4:04 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote:
>
> On Fri, Jun 17, 2022 at 08:00:10PM -0400, Ricardo Signes wrote:
> > Porters,
> >
> > Here's what I think, on the matter of eliminating that pesky magic true
> value.
>
> And here's what I think.
>
>
> I think you and I are in agreement, except for one small matter: I think
> that it'd be useful to say "module evaluated to false, despite having at
> some point enabled yield true, which probably indicates a mistake." If
> this ends up being onerous, I think it's something we can do without. But
> I think it will help users who do what Ovid mentioned doing: writing all
> their code in a block. The feature under discussion is the only one that
> would really be affected by writing your code that way. That's why I think
> it's plausible it's happening.
>
> Why don't we start with just implementing the basic feature and then we
> have a year to think more about the warning if we want. ????
>
> Also, we know it needs a name. I suggest 'module_true'. If the feature
> is on, then this module will be treated as evaluating true. I don't want
> to say 'require_ignores_false' or something because that could imply it
> changes the behavior of "require" in this scope.
>
> 'module_true' sounds very generic.
Having 'require' as part of its name would be good, as it affects how
require is behaving.

I don't get why you wrote that one shouldn't imply that its behavior
changes because that's just what it does:
- "require" ignores the return value to determine if the module was
successfully loaded.

On Mon, Jun 27, 2022 at 10:10 AM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Fri, Jun 24, 2022 at 4:04 PM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>
>> On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote:
>>
>> On Fri, Jun 17, 2022 at 08:00:10PM -0400, Ricardo Signes wrote:
>> > Porters,
>> >
>> > Here's what I think, on the matter of eliminating that pesky magic true value.
>>
>> And here's what I think.
>>
>>
>> I think you and I are in agreement, except for one small matter: I think that it'd be useful to say "module evaluated to false, despite having at some point enabled yield true, which probably indicates a mistake." If this ends up being onerous, I think it's something we can do without. But I think it will help users who do what Ovid mentioned doing: writing all their code in a block. The feature under discussion is the only one that would really be affected by writing your code that way. That's why I think it's plausible it's happening.
>>
>> Why don't we start with just implementing the basic feature and then we have a year to think more about the warning if we want. ????
>>
>> Also, we know it needs a name. I suggest 'module_true'. If the feature is on, then this module will be treated as evaluating true. I don't want to say 'require_ignores_false' or something because that could imply it changes the behavior of "require" in this scope.
>>
> 'module_true' sounds very generic.
> Having 'require' as part of its name would be good, as it affects how require is behaving.
>
> I don't get why you wrote that one shouldn't imply that its behavior changes because that's just what it does:
> - "require" ignores the return value to determine if the module was successfully loaded.

It does not change how "require" acts in the scope of the feature. It
changes how "require" acts when returning from where the feature is
active.

On Mon, Jun 27, 2022 at 10:17 AM Graham Knop <haarg@haarg.org> wrote:

> On Mon, Jun 27, 2022 at 10:10 AM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Fri, Jun 24, 2022 at 4:04 PM Ricardo Signes <
> perl.p5p@rjbs.manxome.org> wrote:
> >>
> >> On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote:
> >>
> >> On Fri, Jun 17, 2022 at 08:00:10PM -0400, Ricardo Signes wrote:
> >> > Porters,
> >> >
> >> > Here's what I think, on the matter of eliminating that pesky magic
> true value.
> >>
> >> And here's what I think.
> >>
> >>
> >> I think you and I are in agreement, except for one small matter: I
> think that it'd be useful to say "module evaluated to false, despite having
> at some point enabled yield true, which probably indicates a mistake." If
> this ends up being onerous, I think it's something we can do without. But
> I think it will help users who do what Ovid mentioned doing: writing all
> their code in a block. The feature under discussion is the only one that
> would really be affected by writing your code that way. That's why I think
> it's plausible it's happening.
> >>
> >> Why don't we start with just implementing the basic feature and then we
> have a year to think more about the warning if we want. ????
> >>
> >> Also, we know it needs a name. I suggest 'module_true'. If the
> feature is on, then this module will be treated as evaluating true. I
> don't want to say 'require_ignores_false' or something because that could
> imply it changes the behavior of "require" in this scope.
> >>
> > 'module_true' sounds very generic.
> > Having 'require' as part of its name would be good, as it affects how
> require is behaving.
> >
> > I don't get why you wrote that one shouldn't imply that its behavior
> changes because that's just what it does:
> > - "require" ignores the return value to determine if the module was
> successfully loaded.
>
> It does not change how "require" acts in the scope of the feature. It
> changes how "require" acts when returning from where the feature is
> active.
>

Examples are king, just explained your text to myself while I wanted to
write 'the other way round', but your're correct:

package A;
# in the scope of package A
use 'require_ignore_false';


# no true return value here, let's make it explicitly return false for
clarity
0;

package B:
my $rv = require 'A';
# $rv is 0 which is false in boolean context

# no error in scope of package B although false is returned

Hope that helps others as well to clarify.

On Mon, Jun 27, 2022 at 01:12:17PM +0200, Alexander Hartmaier wrote:
> package B:
> my $rv = require 'A';
> # $rv is 0 which is false in boolean context
>
> # no error in scope of package B although false is returned


My mind has been changed by Graham Knop's observations that:

* the return value of require is most often used like:

if (eval { require $module }) { ... }

* that if a file is require'd for a second time, the code isn't called
again and the 'true' value (i.e. !!1) is returned rather than whatever
was returned the first time. For example:

Foo.pm:
package Foo;
5;

$ perl -le'print require Foo for 1..2'
5
1

So relying on the actual return value is a poor practice which we should
seek to eliminate. So I now think that the single change in behaviour in
perl should be:

At the point in the core which does the return-from-require
processing, it's behaviour should change from:

if the return value is false, croak, else return the value to the
caller of 'require'.

to:

if 'require_returns_true' was in scope at the point where require
explicitly or implicitly returned:

throw away the return value and return !!1 to the caller of
'require'

else

as before: if the return value is false, croak, else return
the value to the caller of 'require'.


I'm not convinced that having a warning when returning a false value would
be useful. I suspect that most uses of 'use v5.40' will be in new code
(rather than retrofitting an existing module) where a warning won't be
particularly useful. Instead it could generate false positives - for
example, if the last line in Foo.pm file is:

$Foo::some_flag = calc_flag();

then the warning will surface only if calc_flag() returns false,
which might not happen during testing.

So such a warning would only potentially be useful in old code which has
been retrofitted with 'use v5.40', and then only on those rare modules
which actually use a false return to signal failure. I think this is rare
enough to not outweigh the problem of false positives in new code.


--
31 Dec 1661: "I have newly taken a solemne oath about abstaining from plays".
1 Jan 1662: "And after ... we went by coach to the play".
-- The Diary of Samuel Pepys

On Tue, 28 Jun 2022 10:29:13 +0100
Dave Mitchell <davem@iabyn.com> wrote:

> So I now think that the single change in
> behaviour in perl should be:
...
> to:
>
> if 'require_returns_true' was in scope at the point where
> require explicitly or implicitly returned:
>
> throw away the return value and return !!1 to the caller
> of 'require'
>
> else
>
> as before: if the return value is false, croak, else
> return the value to the caller of 'require'.

Yes; that all sounds sensible.

> I'm not convinced that having a warning when returning a false value
> would be useful. I suspect that most uses of 'use v5.40' will be in
> new code (rather than retrofitting an existing module) where a
> warning won't be particularly useful. Instead it could generate false
> positives - for example, if the last line in Foo.pm file is:
>
> $Foo::some_flag = calc_flag();
>
> then the warning will surface only if calc_flag() returns false,
> which might not happen during testing.
>
> So such a warning would only potentially be useful in old code which
> has been retrofitted with 'use v5.40', and then only on those rare
> modules which actually use a false return to signal failure. I think
> this is rare enough to not outweigh the problem of false positives in
> new code.

Also agree.

This feels like it's veering towards some kind of agreement enough that
we should write up a real RFC for the idea.

That, and my "lexically_export" should keep me busy today ;)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Tue, 28 Jun 2022 11:07:34 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> This feels like it's veering towards some kind of agreement enough
> that we should write up a real RFC for the idea.

Actually it seems Ovid already started writing one up:

https://github.com/Perl/RFCs/pull/20

I've added some comments.

Ovid: Do you think you'll be able to tidy this one up and aim it
towards agreement with the discussions here, or should I create a new
one?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, 29 Jun 2022 15:16:45 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> On Tue, 28 Jun 2022 11:07:34 +0100
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > This feels like it's veering towards some kind of agreement enough
> > that we should write up a real RFC for the idea.
>
> Actually it seems Ovid already started writing one up:
>
> https://github.com/Perl/RFCs/pull/20

Oops; I have been a victim of the multiple-clipboards "feature" of X11.

I meant

https://github.com/Perl/RFCs/pull/16

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, Jun 29, 2022 at 4:16 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> Actually it seems Ovid already started writing one up:
>
> https://github.com/Perl/RFCs/pull/20
>
> I've added some comments.
>
> Ovid: Do you think you'll be able to tidy this one up and aim it
> towards agreement with the discussions here, or should I create a new
> one?


I've tidied it up based on your feedback. If you feel a new one would be
better, that's fine, too. I'd just be happy to see it get in to core.

Curtis "Ovid" Poe
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/

On Sat, Jun 11, 2022 at 09:37:00AM +0100, Neil Bowers wrote:
> > Can someone show an example, ideally on CPAN, where this gets used?
>
> I _think_ you were asking for an example of someone using the return value from a require. In which case:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>
> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>
>     if ( $] >= 5.006 && $] < 5.007003  ) {
>         eval { $data = require 'unicode/Name.pl'; };
>     }
>     elsif ( $] >= 5.007003 ) {
>         eval { $data = require 'unicore/Name.pl'; };
>
>         # since v5.11.3, unicore/Name.pl creates subroutines
>         # they end up in our namespace, so get rid of them
>         undef *code_point_to_name_special;
>         undef *name_to_code_point_special;
>     }
>

And it sounds like this is use case for `do`, rather than `require`.

--
Philippe Bruhat (BooK)

No matter how you dress a cow, it still gives milk.
(Moral from Groo The Wanderer #46 (Epic))

On Sat, Jun 11, 2022 at 02:01:35PM -0600, Karl Williamson wrote:
>
> I feel compelled to point out that the file read-in in this example,
> unicore/Name.pl, has the following text at its top
>
> # !!!!!!! INTERNAL PERL USE ONLY !!!!!!!
> # This file is for internal use by core Perl only. The format and even the
> # name or existence of this file are subject to change without notice. Don't
> # use it directly. Use Unicode::UCD to access the Unicode character data
> # base.
>

Here's my list of excuses:

1. Acme ;-)
2. Back then, I couldn't find another way to get the list of all Unicode
character names. I believe the functions in Unicode::UCD take a
codepoint as parameter, but provide no way of getting the whole list.
Is there a better way?

--
Philippe Bruhat (BooK)

When the employee is a fool, so is the employer.
(Moral from Groo The Wanderer #26 (Epic))

On Sat, Jun 18, 2022 at 11:13:18AM -0400, Ricardo Signes wrote:
>
> my $str1 = do { use utf8; "????" };
> my $str2 = do { "????" };

If I understand correctly, `use utf8` is less about the encoding of the
file (Perl code is ascii anyway), and more about what the literal
strings in the lexical scope actually contain (either a utf8 string, or
a byte stream), right?

--
Philippe Bruhat (BooK)

The best thing about being apart is getting together again.
(Moral from Groo The Wanderer #39 (Epic))

On Wed, Aug 3, 2022 at 11:59 AM Philippe Bruhat (BooK) <book@cpan.org>
wrote:

> On Sat, Jun 18, 2022 at 11:13:18AM -0400, Ricardo Signes wrote:
> >
> > my $str1 = do { use utf8; "????" };
> > my $str2 = do { "????" };
>
> If I understand correctly, `use utf8` is less about the encoding of the
> file (Perl code is ascii anyway), and more about what the literal
> strings in the lexical scope actually contain (either a utf8 string, or
> a byte stream), right?
>

No it is the encoding of the file. Perl code is not ASCII, it's bytes (you
can use non-ASCII bytes in symbols as long as they end up being interpreted
as word characters). Without use utf8, the bytes are interpreted as
codepoints with the identical value (which due to the mapping being
identical, is essentially a process of decoding it from ISO-8859-1). With
use utf8, the bytes are interpreted in Perl's internal upgraded encoding,
which essentially decodes it from UTF-8.

Perl has no concept of the meaning of what strings contain, they logically
contain a series of codepoints either way. use utf8 just changes how those
codepoints are derived from the bytes of the source code, along with the
rest of the code.

-Dan

Porters,

I have replaced the PR for "yield true" with one that provides more specifics, based on suggestions from Dave M. that seem sufficient and which he says would be easy to implement. I have moved it to exploratory status, but I don't expect much more exploration or discussion is required. "Surely" we're about ready to receive an implementation?

You can see it on GitHub <https://github.com/Perl/RFCs/pull/27>.

--
rjbs