In a recent PSC call (whose notes I still have to write up - sorry about that), a thought was expressed that we should do more "dogfooding" - namely, using our own features in our own code. I'd like to encourage more people to help us achieve this. ((Wikipedia has more on the origin of the phrase https://en.wikipedia.org/wiki/Eating_your_own_dog_food )) I personally find it very useful to be a bleeding-edge user of a lot of my own new features; many of my personal-use CPAN modules and programs are dependent on Object::Pad, async/await, and various of my Syntax::Keyword::* modules. It's useful to be both implementer and user of these new features, so as to get a good feel for what and how it should be designed, used, extended. We should do the same in core perl; currently we do not. For example, I notice that basically nowhere in any of our shipped .pm files are we using any of the following features that are already present in perl releases: * Postfix deref * Sub signatures * The `isa` operator * try/catch blocks nor any of the 5.35.x-added things like * `defer` blocks * Stable booleans I'm also thinking about what'll happen when I merge the new `builtin` functions related to the new stable-boolean ability. I would like us to fix this shortcoming. One of the unfortunate outcomes of the first (dare I mention it) "Perl 7" attempt, was our realisation that so much of perl core's own shipped .pm files aren't even strict- or warning-safe. That's looking better now, but we still have almost no coverage of any of these other more-modern features. Shortly after the release of try/catch in 5.34.0, a large bug was found in it that I fixed in time for 5.34.1. I feel that if try/catch had been used a lot more in core already by that point, it would have been found and fixed within the 5.33 development cycle and not made it out that far. Now, not every shipped .pm file is suitable for this - there are files that are dual-life and have their own existence on CPAN. Also files related to the build process (e.g. under regen/) have to execute with an installed perl, which may be of an older version than the target perl being built. But still, the majority of our .pm files ought to be using a significantly newer standard of perl than they currently are. I would like to encourage folks to assist on this. Again this is one of those tasks that doesn't need any in-depth C or XS knowledge; any Perl author ought to be able to take a core .pm file or two, and update it with their favourite "new feature" - perhaps one from the list above. I would be happy to assist and walk people through how to test and submit these as PRs against core perl, and help review and merge the changes that come out. Who wants to help us out with this? -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Next