New RFC: "yield_true" at end of compilation

[Ovid]

This RFC is to eliminate the need for a magic true value (usually a hard-coded trailing 1) being required in code we use.

I guess as to the RFC number. If there is a process for assigning them, I've missed it. My apologies.

Better names than yield_true are welcome. I was tempted to go with use feature 'neo'; because "Neo is the One", but it's terrible name, even though it amuses me :)

[haarg]

It is possible for a file to explicitly return a false value. I'd expect that would just be ignored with this feature enabled, but it's probably worth specifying.

[leonerd]

Typo, you probably didn't mean the "1" in here

[leonerd]

The intention of having it be a named feature, is that a future version bundle will include it, so you'll get it automatically with, perhaps,

use v5.40;

[haarg]

A prototype implementation exists at https://metacpan.org/pod/true

[leonerd]

Something to think about is that while most modules just put "1" or some other dummy true value, there are some modules that make use of the return value, because it becomes the value returned by a require. In particular, it is not uncommon to yield the package name itself, when that is an object class, so you can do things like

my $obj = (require Some::Object::Class)->new;

I don't think we want to complicate this feature idea by suggesting we'd allow customisation of the true value being returned, but perhaps if we're returning some value anyway, the string form of the package name is just as good as any, and makes this use-case still work. (And anyone who writes package 0 deserves what they get :P)

[Corion]

I'm mildly opposed to simply returning 1 because I still entertain the idea of actually (optionally) returning an object. Returning the package name is a good thing though. The return value of require My::Example; should always return the package name, even on the second invocation then:

for (1..2) {
    my $factory = require My::Example;
    my $handler = $factory->new($_);
}

[haarg]

Changing the return value of require seems like a separate issue from what this RFC wants to address.

If you wanted require to always return the same value, and for that value to come from the file, you need a new location to store these values. This would probably mean a new superglobal to go along with %INC. And it would usually be useless because most modules return 1. I don't think this is a very good idea.

If you wanted require to always return the package name, it's a separate issue from this RFC because that means ignoring the return value from the file. It also presents a problem because require doesn't actually take package names. It takes file path fragments. Foo::Bar is translated to "Foo/Bar.pm" at parse time. This would then need to be converted back to a package name, or do something else. I don't think this is a good idea either.

Instead, it's probably best addressed with a builtin::load or similar routine that accepts a package as a string. This has been discussed in the past, and solves other problems. Module::Runtime has a use_module function that behaves like this, returning the package name.

[leonerd]

@haarg makes some good points about returning odd values, so yes probably best to stick to just "1" (or more likely the new "true" value)

However, in saying the word "return", does raise an interesting point. Most modules currently do not return a true value, they simply yield one by being the final expression in the block. It is possible to explicitly return a value. Presumably this is good enough to override whatever default-true value this feature would propose.

package Some::Module v1.23;
use feature 'yield_true';

return "a different value";

[haarg]

Would returning a false value also override the true value? It feels a bit strange to me. Maybe an explicit return in the context of yield_true should be an error.

[Ovid]

I accidentally wrote this in master instead of a branch. Closing this in favor of #16

Issues raised here have been addressed. Sorry 'bout that.

[demerphq]

On Sun, 3 Apr 2022, 17:44 Graham Knop, ***@***.***> wrote: It is possible for a file to explicitly return a false value. I'd expect that would just be ignored with this feature enabled, but it's probably worth specifying.

That would be bad. There is a difference between returning false and dieing during require. Returning false allows the code to be required again, possibly after fixing the cause of the false return, dieing does not allow the file to be loaded again. (Fixing part of this, where death is signified by a specific undef, is on my todo list.) Therefore this feature must distinguish and deal with modules which explicitly return false. Yves

…

[haarg]

I'm not convinced that is a behavior that needs to be preserved under this feature. Allowing a module to be required multiple times is mostly a surprising behavior, and anything expecting to handle that programmatically would need to either be working with known modules or need some external way of communicating what is needed to load the module. And if the caller knows it can attempt loading the module multiple times, it can remove the %INC entry to allow it. Or, the module in question can disable (or leave disabled) this feature.