Porters, Here's what I think, on the matter of eliminating that pesky magic true value. In "Foo.pm" we want a way to signal that when require-d, it is treated as if it had evaluated to true, even if (say) the last statement is "0;". The biggest question, for me, is how we signal that. The mostly-undebated option here has been: use feature 'xyzzy'; # for some value of "xyzzy" The problem with that is that "use feature" is always lexical, but it's not clear that this makes sense lexically. require v5.40.0; # assert version number is high enough but do not enable features do_some_stuff; package Foo { use v5.40.0; # strict is on } # strict is off again more_code_here; 0; # EOF If the yield-true feature exists and is enabled by v5.40, what should happen here? If it's treated as if on, we're violating the expectation of lexical effect. If it's treated as off, we've created a new kind of feature that only matters at top-level scope in a file. If a programmer has written all their code inside a "package NAME BLOCK" structure, which previously would have no particular problem, they now don't fully benefit from "use vX". All of this *makes sense*, but a large part of getting rid of the need for the "magic true value" is to avoid confusing programmers who don't want to think about the weird under-the-hood stuff here. I don't think we're avoiding enough confusion. The error "Foo.pm did not return a true value." could be worse, but it's not the best, either. Issuing a "use vX doesn't make sense at non-top-level" also seems unappealing. I don't have a great solution to offer. So far what I've got is: * if "require" errors because of a false value * and the file required did enable the feature * but did not *explicitly* disable it, subsequently * *then*, a warning is issued "File.pm did not return a true value. The xyzzy feature, which would eliminate this error, was enabled at line 123 but only in a limited lexical scope, ending at line 321." I'm not in love with it. -- rjbsThread Previous | Thread Next