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 MendozaThread Previous | Thread Next