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

Re: Pre-RFC: yield true feature

Thread Previous | Thread Next
Dan Book
June 7, 2022 00:40
Re: Pre-RFC: yield true feature
Message ID:
On Mon, Jun 6, 2022 at 8:17 PM Yuki Kimoto <> wrote:

> 2022-6-7 7:07 Neil Bowers <> 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]
> 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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About