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