Front page | perl.perl5.porters |
Postings from June 2022
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. -DanThread Previous | Thread Next