On Fri, Sep 3, 2021 at 1:30 PM Felipe Gasper <felipe@felipegasper.com> wrote: > > > On Sep 3, 2021, at 12:48 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org> > wrote: > > > > So, let's say we were to implement a new require-like builtin that we > wanted to be a core language feature and live forever. Would it be > something other than something really close to Module::Runtime's > use_module? I have some thoughts, but I think the basic question here is: > > > > Is it enough to say "v5.x will provide load, which will take a module > name and optional version, then load that module (or die trying) and call > ->VERSION on it. > > Thereâs an opportunity here. > > Occasionally Iâve implemented plugin-like things where I require() a > module that isnât actually ârequiredâ. To differentiate âno such module > existsâ from âfailed to load moduleâ Iâve had to resort to pattern-matches > on the thrown error, which is ugly. > > I know the topic of structured or otherwise-machine-parsable errors is a > quagmire, but would it be feasible to implement this new runtime module > loader in such a way that a caller can reliably differentiate those two > fundamentally-distinct failure states? haarg was working on a Module::Runtime replacement that has this capability with a function called "try_require_module", which returns true on success, false on not found or insufficient version, and an exception on other errors. I think it is a great API, but unfortunately has not been put through the rigors of CPAN workshopping yet. -DanThread Previous | Thread Next