develooper Front page | perl.perl5.porters | Postings from March 2021

PSC #011 2021-03-19

Thread Next
From:
Sawyer X
Date:
March 24, 2021 17:23
Subject:
PSC #011 2021-03-19
Message ID:
CAMvkq_QmY4XK47QXGemAbtjOyQ7aZPBW1Na+unSnuKMeYf-UbA@mail.gmail.com
In the... hmm... the excitement of this week, let's call it, this
report had not been sent yet. My apologies.

The last Perl Steering Council meeting was held on Friday, March 19th.

Attendees: Ricardo, Neil, Sawyer.

We discussed our proposed plan for the Future of Perl, the trim()
function, and as a bonus topic (despite being overtime, as we always
are), weak vs. non-weak keywords, and how they can fit (or not fit)
into future keyword changes in Perl.

On our proposed plan, we spent another week iterating over the
document. We were considering whether 5.34 should lead to 7.2
(allowing developer releases in 7.1.x. We consider this more relevant
for the jump from anything that isn't 5.x, rather than every major
version number. We also discussed prototypes, signatures, and the idea
of "long-term features" as language levers. In this respect, just like
"strict" and "warnings" should be "long-term features", we might want
signatures to always remain a feature lever to allow disabling them,
whether they have one state or the other as a default.

We shared our plan with the core team in order to begin discussing it.
This had mixed reviews, ranging from "looks good" to "absolutely not."
That's okay because we believe we have enough foundation to begin
earnest discussions. Our plan was not meant to be the end-all, but the
fertile ground on which to discuss it productively.

On trim(), we briefly discussed changing our expectation of how it
should work. There is a lively (in a positive sense) debate on GitHub
and we raised questions from there and asked ourselves what we think.
Not much to say that isn't shared on the GitHub issue (which is what
we all preferred), but we firmly disagree with context-awareness of
this keyword and we maintain (at least at the moment, the discussion
on the ticket is still ongoing) that the trim() keyword should have
similar semantics as chomp(), for better or worse.

The interesting bit from trim() is the broader discussion on creating
facilities for adding keywords that do not continue to expand (and
possibly overwhelm or litter) the user's namespace. We touched on this
briefly but this seems to be a ball of hair that requires more thought
to be untangled.

One additional topic we reached from the trim() keyword is weak versus
non-weak keywords. If we introduce non-weak keywords, we would still
want warnings in two major releases (as it is with normal keywords).

-- Sawyer

Thread Next


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