Mailing List Archive

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