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