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

Re: Pre-RFC: yield true feature

Thread Previous | Thread Next
From:
Nicolas Mendoza
Date:
June 22, 2022 01:56
Subject:
Re: Pre-RFC: yield true feature
Message ID:
901d1dd4-bdc7-24a6-f3f6-818963f91126@pvv.ntnu.no
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About