develooper Front page | perl.perl5.porters | Postings from January 2022

PSC #050 2022-01-14

From:
Paul "LeoNerd" Evans
Date:
January 20, 2022 23:32
Subject:
PSC #050 2022-01-14
Message ID:
20220120233230.1a217de5@shy.leonerd.org.uk
Present: Neil, Paul, Rik

Signatures
----------

We briefly revisited the list of options from last time. Especially in
light of Rik's recent mini-benchmark message (showing that signatured
subs are already faster than the equivalent `@_`-unpacking code), there
doesn't feel to be a huge driving force for requiring the performance
boost of a no-snails world, even if we could get to it. Reviewing
various other comments from the mailing list, Option 1 seems to be the
way forward. Notably, Dave M hasn't given an opinion yet and we're
still keen to hear from him, so

 [neilb] to email Dave to enquire

Paul has started working on a core perl branch that warns at compile
time about uses of `@_` in signatured subs and claims them
"discouraged", but otherwise has no behavioural effect, and no changes
at runtime. We may be able to make a case to nudge "contentious freeze"
until Feb in order to get that merged in time for the freeze.


Builtin
-------

Little change since about a month ago. Latest dev release has the start
of it present, though no `experimental` warnings yet. These still need
adding. Not anticipated to be particularly difficult, just need to find
a time.


Ovid's Corinna RFC
------------------

This (proto?) RFC is much bigger than the usual ones. Does it need a
bigger process? More community visibility? Should PSC invite discussion
from others on a more formal basis?

The RFC is split into 7 stages, which is useful but raises questions on
how to schedule that against Perl releases. It is also an open question
on how "experimental" tagging will go with this. Will it all be under
one large experimental flag, or will parts of the design eventually
stabilise before other parts?

It would be good to get more public scrutiny from the wider core
developers on this one. Perhaps we need each step as a (full) RFC,
linking to the overall design.

Likely the whole thing will remain experimental until the end when all
of it is done. In each yearly release we'd aim to add at least one more
(or hopefully several) of the next phases from the list, until it
becomes complete.


Other 5.36'isms
---------------

We were close to full time, but did a quick review of any other things
we thought might be good to get into a 5.36 release:
  [paul]: try/catch/finally (no RFC but a mailing list thread)
  [neilb]: configure for taint (pre-RFC 0012)
  [paul]: de-experimentalise `isa`
  [rik]: warning when any regular (numerical) bitwise operator is
    forced to operate on a string value

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About