Front page | perl.perl5.porters |
Postings from February 2022
PSC #053 2022-02-04
From:
Paul "LeoNerd" Evans
Date:
February 9, 2022 10:18
Subject:
PSC #053 2022-02-04
Message ID:
20220209101815.6e0618ef@shy.leonerd.org.uk
Present: Neil, Paul, Rik
## Signatures
We again talked about signatures. The current state is that there is
now a new warning, triggered on uses of @_ within signatured subs. This
is in a subcategory of "experimental". While most experiments are
indications of "here's a new thing we're adding", this one is more
about "we'll be taking this away. probably", but that's fine - it still
fits the overall description of "experimental". We should remember to
make this clear in the 5.36 release notes.
It's getting too late in the 5.35.x development cycle now to consider
making any more significant changes to actual behaviour, so it seems
we'll ship like this in 5.36 and continue working on the performance
changes of skipping @_ setup in 5.37.x instead.
## SvUTF8
Felipe's idea has two parts to it: Changing the XS-visible API names,
and changing the Perl-visible ones.
Changing the XS-level things would be a huge task to arguably-little
benefit - everyone would still have to know what the words mean; and
the old names would have to be maintained for a long time to avoid
breaking code that hasn't yet been updated. It likely makes the
situation worse, not better. Regrettably a bad name was picked a long
time ago, but this may now be too ingrained in the perl code ecosystem
to be able to change.
Changing the Perl-visible names however is a different story. We now
have the `builtin::` namespace into which we could place better-named
new variants of whatever bits of API we feel appropriate to expose to
Perl authors; the existing functions in the badly-named `utf8::`
namespace can then throw deprecation warnings.
Overall we'll park the suggestion as a whole, but Rik will post to p5p@
with further ideas on expanding this second part.
## Sharing the RFC Tracker
We discussed whether it would make sense to publish the tracker sheet
so it's publicly readable. We decided there's no reason to keep it
secret, so after we've had a chance to neaten it up and prepare it for
a public showing we'll do that.
## perldelta
We discussed making a minor change to the release process, as suggested
by Dan Book, wherein the perldelta.pod file for a given release will
also be present under its fully-numbered name within that release; e.g.
perl5359delta.pod in the v5.35.9 release.
## Ovid's "module" RFC
We looked at a draft reply for this suggestion, which will be posted
soon.
## use VERSION vs use strict
We discussed the various complications on how `use strict` interacts
with `use VERSION`. We decided the current model is needlessly complex
and complicates the otherwise-simple mental model of what `use VERSION`
is supposed to do. We agree we should tidy it up a bit ahead of the
v5.36 release, especially given we're intending to make more use of
that ability in code, documentation, and so on.
We decided there ought to be a warning printed when someone attempts
the now-broken legacy behaviour of downgrading a `use VERSION` from
above 5.11 to below it, where the behaviour would now be different.
## CPAN.pm in bleadperl version bump
The version of CPAN.pm that shipped with 5.35.8 has troubles with https
and bootstrapping. There's a TRIAL version of the module on CPAN which
fixes it, and is now present in bleadperl. Hopefully we can get this
bumped up to a real release in time for 5.35.9.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
-
PSC #053 2022-02-04
by Paul "LeoNerd" Evans