Move to a branch and address issues raised in #14

Author: Ovid

rfcs/rfc0018.md

@@ -10,8 +10,8 @@
 ## Abstract
 
 This RFC proposes a `yield_true` feature. When used, the current Perl _file_
-containing `use feature 'yield_true'l` will automatically return a true value
-after successful compilation, eliminating the neeed for a "1" (or other true
+containing `use feature 'yield_true';` will automatically return a true value
+after successful compilation, eliminating the need for a "1" (or other true
 value) at the end of the file.
 
 ## Motivation
@@ -26,13 +26,18 @@ _doesn't_ end with a true value but nonetheless compiles just fine because
 _something_ in the code returned a true value and the code compiles as a
 side-effect.
 
-
 ## Specification
 
     use feature 'yield_true';
 
 Code using the above does not need to return a magic true value when compiled.
 
+If the module explicitly returns a false value, we should consider if this can
+be ignored (I suspect this is usually a bug). However, the module author
+_might_ have conditional logic to explicitly return a false value in case
+there's a missing dependency (or for some other reason). Discussion might be
+useful here.
+
 ## Backwards Compatibility
 
 There are no compatibility concerns I'm aware of.
@@ -47,19 +52,50 @@ None. See above.
 
 ## Prototype Implementation
 
-None.
+There is a prototype implementation at [true](https://metacpan.org/pod/true).
 
 ## Future Scope
 
-I believe this is complete.
+Due to this being a named feature, this can eventually be the default behavior
+when `use v5.XX;` is used.
 
 ## Rejected Ideas
 
-None that I'm aware of.
+It's been discussed that we should return the package name instead. This
+supports:
+
+    my $obj = (require Some::Object::Class)->new;
+
+However, per 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.
+
+Thus, we prefer simply returning `true` (or `1`).
 
 ## Open Issues
 
-None that I'm aware of.
+* Should returning a false value be ignored?
+* Should any explicit return be an error?
 
 ## Copyright