PSC #024 2021-06-11

PSC #024 2021-06-11
Present: Nick, Rik, Neil


Supported Platforms
We talked about supported platforms, and some thoughts I'd put together and iterated on with Nick. I'll post those, and we agreed we should try to get to something "good enough", which will be better than what we have now. I'll post something on the relevant thread.


`no strict` before `use vN`, and what that means for warnings in 5.36 bundle
We had a loong discussion about `no strict` before `use vN`, and what this should mean for `no warnings`. This was prompted by my response on the thread about this[1], which Rik had replied to[2]. We have pages of notes. I argued that we should focus on least surprise for the bulk of Perl programmers – not complete beginners, but nor the handful of people who understand everything in the referenced threads. Rik quoted Larry at me[3]. I think we converged. Rik is going to write up a proposed mental model for this and email it to the list.


Assignment to undef, and a quirk
Tony C submitted a PR on 2021-06-02 which changes the behaviour on assigning to undef within a ternary[4]. We discussed whether assigning should be legal in any context. But we then ended up looking at what was really going on with ($x ? $y : undef). Rik started dumping out op trees for different examples, and bouncing back & forth with Nick on what was going on. Oh how naive I was, thinking the previous topic went on for a long time. Rik is going to email a summary of this, with a suggestion for what might change.


try/fix and 5.34.1
We had a brief chat about try/fix and #18855. We'll ask Paul to prioritise fixing this for a 5.34.1 release. The fact that this wasn't caught before 5.34.0 suggests it didn't get any serious testing, so we talked about the next to ensure better testing prior to 5.34.1, so we don't get caught out again. We ask people who've used CPAN try/catch modules to exercise this, once Paul has fixed #18855.


When does `isa` stop being experimental?
We talked about "isa", which is currently experimental[5]. I asked what the criteria are for dropping the experimental from this? Perlpolicy says 2 stable releases and 1 release cycle with no design-changing bugs[6]. We think "isa" looks good, but has it been used, and seriously abused with all sorts of weird edge cases? Probably not. Nick will put together a list of ways to abuse interfaces in Perl, which we're hoping might end up somewhere in pod/, and which we’ll use to exercise isa a bit more.


Bug queues for dual-life modules
Data::Dumper is a dual-life module (released with Perl, but also gets independent releases on CPAN), upstream blead (changes should be done in blead, and then a release done to CPAN). Nick recently fixed some bugs that had been languishing because Data-Dumper has its own RT bug queue. Jim submitted a PR to change the CPAN release to direct people to Perl's github issues. Neil and Nick had different thoughts on this, so we discussed it.

In the end we agreed that the general policy for dual-life modules should be: perl's git issues queue for upstream blead, and their own issues tracker for upstream CPAN. There are some upstream blead dists that have their own repo – we'd like to move these repos, and their committers, into the perl organisation. This seems like the right place for upstream blead dists, and also means we'll be able to move tickets between repo's. Neil will put a +1 on the PR and Rik will approach the upstream blead repo owners.


The RFC process and formatting quadmath floating point numbers
In the context of the new RFC process, sisyphus said he'd like to see improvements in formatting of floating point values[7]. He wasn't sure whether he should submit an RFC, given he won't be in a position to implement it; and there are potentially licensing issues. Nick really got into his stride discussing quadmath and the like, but I can't do it justice. But the end result was: yes, please kick off the idea on p5p (in a separate thread), and we'd like to see this become an RFC. There's an existing C implementation which may have licensing issues, but we'll cross that bridge if we get to it.

We discussed a couple more points related to RFCs. Nick will send at least one email as a result.


The -Dusedefaultstrict Configure option
Jim has pointed out[8] that if you configure Perl with -Dusedefaultstrict, then it won't currently pass tests, due to some dual-life modules that are upstream CPAN. He wondered if we should remove the Configure option. We think a better approach is to first get those distributions all strict-clean, and then we can separately decide whether we think this Configure option should stay. I'll follow up on this, starting with Text-Tabs+Wrap.


Neil, Rik, Nick


[1] https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260328.html
[2] https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260329.html
[3] care to guess which one?
[4] https://github.com/Perl/perl5/pull/18848
[5] https://github.com/Perl/perl5/issues/18754
[6] https://perldoc.perl.org/perlpolicy#experimental
[7] https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260361.html
[8] https://github.com/Perl/perl5/issues/18872

• PSC #024 2021-06-11 by Neil Bowers
• Re: PSC #024 2021-06-11 by Tony Cook
• Re: PSC #024 2021-06-11 by Ricardo Signes
• Re: PSC #024 2021-06-11 by Tony Cook
• Re: PSC #024 2021-06-11 by Yuki Kimoto
• Re: PSC #024 2021-06-11 by mah.kitteh via perl5-porters
• Re: PSC #024 2021-06-11 by Dan Book