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