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

PSC #031 2021-07-30

Thread Next
From:
Paul "LeoNerd" Evans
Date:
July 30, 2021 16:24
Subject:
PSC #031 2021-07-30
Message ID:
20210730172425.1b508fe7@shy.leonerd.org.uk
Present: Paul, Rik. Neil was on vacation.

## Outstanding Issues

No outstanding actions from last week - the `G_LIST` PRs are now all
done.

## Digression

We had a 5-minute digression from the agenda that strayed onto Raku's
colon-syntax for adverbs, and the observation that in Perl the
following is still a syntax error:

    func( :name(1) );

Perl could maybe use that, or do something nicer, if we started making
a distinction about colons and significant whitespace before/after to
work out whether something is a label or not. And wouldn't it be nice
to have a real AST and not rely on hacks like PLS or PPI/PPR... More on
that another day perhaps.

## Review of perlexperiment

We skipped over the ongoing review of the Quirks document, because Neil
was absent.

We instead looked over the review of perlexperiment, decided to
slightly clarify what "experimental" even means, and used that to try
to classify the currently-running experiments into broad categories. We
quoted the definition from perlpolicy, which states:

    If something in the Perl core is marked as experimental, we may
    change its behaviour, deprecate or remove it without notice. 

    Experimental features will only have their experimental status
    revoked when they no longer have any design-changing bugs open
    against them ...

which suggests that "experimental" is mostly about the design shape,
and not the implementation itself. It's also about how much feedback
we've received about them. With this in mind the current classification
looks like:

    Consider whether they're "done":
     * isa
     * :const subs

    Design still ongoing:
     * try/catch

    Insufficient uptake for an answer to be obvious:
     * unicode private character hooks
     * unicode property wildcards
     * variable-length lookbehind
     * bracketed extended charclass

    Probably needs changes before landing:
     * signatures
     * regex strictures (this should be moved to strict.pm - see
       below)
     * refaliases
     * declared refs

    Kill it with fire:
     * smartmatch

    "Is this experimental?":
     * installhtml
     * pluggable keyword API

On this last one, the pluggable keyword API, Paul suggests instead core
should gain a better abstraction mechanism, perhaps XS::Parse::Keyword
or something similar, to act as a decoupling mechanism between core
internals and keyword module authors. That would remove much of the
current reasoning why pluggable keywords remain "experimental".

## More strictures

We looked at trying to resolve the logjam that is the fact that
`strict.pm` implies just three strictness flags (vars, refs, subs) and
we seem unable to add more. The shape we came up with is that it would
be nice if `strict.pm` had versioned bundles, like `feature.pm` does,
and that an undecorated `use strict` really meant

    use strict ':5.8';

Furthermore, much like the version bundles you get from `use vX`
turning into `use feature ':X`, the same should be done with `strict`
(and `warnings` while we're at it). This would give us the freedom to
one day add more strictness flags - like `use strict 're'` or anything
else that might come along.

Rik predicts: Somebody’s gonna say “but I want my CPAN-published code
to use warnings ':latest'”. What do we say? Either we add it or we let
somebody implement it on their own because $^V exists.

People can always write:

    use warnings ":$^V";

This still leaves the open question of what does `use strict ':all'`
really mean. Rik: “use strict ‘:all’;” means “use strict ‘:5.8’” but
“no strict ‘:all’” means all for real. Paul: But authors should have
known it was always a ticking time-bomb in their code anyway, right? ;) 

## use v5.36 to imply use utf8

Rik wants `use v5.38` to enable `use utf8`, and will post a message on
perl5-porters@. [he's already done so].

## Retroactive non-experiments

The idea is that, for example, `use v5.20` introduced experimental
postderef.  Later, it became not only non-experimental, but even on by
default.  It never changed behavior from v5.20.0 until then.  It should
be possible to turn it on in v5.20 without `use experimental` but
instead something like `use feature v5.24 'postderef';` which would
imply "I want to use a feature that was experimental now, but became
stable without changing since now."

We discussed various ways this might be done, but all seemed to rely on
shipping some sort of dual-life module out of core onto CPAN, so older
perls can import it. This could be called `futuristic.pm` which would
be "experimental, but only safe things for your $^V" but "use feature"
eliminates one more name and some code.. 

Or maybe we could find a way to work it into `feature.pm` itself. The
$VERSION of feature now matters more because it's how people declare
the version of feature.pm which would enable the feature but disable
the warning.  Tying that to perl version would be nice, and maybe easy.


-- 
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


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