De-experimentalising "signatures"

[leonerd]

use feature 'signatures'; was added in 5.20 - May 2014 (over 6 years ago). Since then, it has seen some minor adjustment to the order of signatures vs. attribute notation; swapped in 5.22 then back again to its now-current form in 5.24 - May 2016 (over 4 years ago).

It has remained "stable" (i.e. not being changed) in its current form ever since then, yet the "experimental" feature tag remains.

Why?

I know Dave M has plans to add lots more things (type assertions, generic query syntax, named variables, etc...) and I'm excited about and definitely want to see many of those things. But I don't know of any firm reason why signatures in their current form need to be marked "experimental" to do so. All over the language we are able to experimentally add new things without marking the entire surrounding context as "experimental".

In the meantime, a lot of feedback I've been seeing for a long time on Freenode #perl, and more recently at FOSDEM over this weekend, is that folks don't want to wait, or aren't allowed to use signatures as they stand, because it is still marked "experimental" and thus they are forbidden by whatever local policy development houses may have. Yet other developers are simply put off by the scary "e" word. I have heard - on more than one occasion - that devs have been firmly told by their manager "do not use signatures" for the sole reason of them being "experimental".

I would therefore like to propose that signatures - in their current form unchanged between 5.24 and 5.32 - be declared no longer experimental and promoted to a fully-fledged first-class language feature. Any further additions (which as already mentioned are very welcome and keenly anticipated) can perhaps be done either under a new experiment name, or by adding the "experimental" warning to that part of the syntax alone. I don't see why signatures as a whole should still be declared experimental. Many developers and CPAN modules are already using them as if they were stable first-class features. I think by now the ship has already sailed on us ever changing any existing details of them.

(cross-posted to https://www.nntp.perl.org/group/perl.perl5.porters/2021/02/msg259019.html )

[kraih]

The Mojolicious community would very much appreciate this.

[shadowcat-mst]

Now we seem to have settled on a specific ordering for attributes, I think we might as well de-experimentalize them.

Of course, the people actively traumatised by my tendency to write accessors as

sub foo :lvalue ($self, $new = return $self->{foo}) { $self->{foo} = $new }

may disagree with this, but I'd be happy to share my next sertraline order from hong kong with anybody actively troubled my this trick.

[jmaslak]

The long length they have been left "experimental" has I think reduced the utility of the experimental tag as a warning. If features remain "experimental" in essentially an unchanged form for many years, particularly features like signatures, it encourages people to just take the risk and use it in production code. My vote doesn't matter, but I'd echo others that think it should no longer be experimental.

[Ovid]

I've had several clients use signatures in production code because it really does a fantastic job of reducing bugs with unpacking @_, and passing the wrong number of arguments.

It's time for them to no longer be experimental.

[leonerd]

Reddit /r/perl has now got hold of it too, and generally seem to be in support of this idea.

https://www.reddit.com/r/perl/comments/lezisy/deexperimentalising_signatures/

[EvanCarroll]

For what it's worth, cPanel uses signatures. We've probably been doing it for a year now. We've got a very large code base that is utilizing them. None of our code uses complex self-referential defaults (that I've seen) as presented by @shadowcat-mst. In my opinion, they've made our code far more maintainable than otherwise would have been.

I believe the only problem area we have is tooling around them. For example, I've ran into both of these questions in working with them,

• https://stackoverflow.com/questions/63836726/how-can-i-test-a-signature-violation-without-calling-a-perl-function
• https://stackoverflow.com/questions/63836449/how-do-i-get-the-signature-of-a-subroutine-in-runtime

I would also point to PPI not being able to distinguish between signatures and prototypes as potential problem area.

• https://github.com/Perl-Critic/Perl-Critic/issues/591
• https://github.com/adamkennedy/PPI/issues/194

I do not believe any of these areas should hold up the removal of the experimental tag.

DISCLAIMER: The views, ideas, thoughts and opinions demonstrated by the content of this message do not necessarily reflect the views, ideas, thoughts and opinions of cPanel, L.L.C.

[Grinnz]

I would also point to PPI not being able to distinguish between signatures and prototypes as potential problem area.

For what it's worth, this isn't something the signatures feature can solve anyway except by changing to use an entirely different syntax (i.e. square signatures) which isn't happening.

[Leont]

The long length they have been left "experimental" has I think reduced the utility of the experimental tag as a warning.

Yes, this. An experimental feature should either be accepted, be worked upon or be removed. This stalemate is highly undesirable.

[leonerd]

I would also point to PPI not being able to distinguish between signatures and prototypes as potential problem area.

For what it's worth, this isn't something the signatures feature can solve anyway except by changing to use an entirely different syntax (i.e. square signatures) which isn't happening.

Yeah - this is a slightly concerning one. It is of course far too late to change the syntax shape of the things, so about all we can do is aim to get some decent-enough heuristics to try to detect if the signatures feature is in scope at the time.

Certainly, any appearance of

use feature ..., 'signatures';
use experimental ..., 'signatures';
use VERSION; # for some future version that might enable it by default

Is one big clue. Another could be some maintained list of alias modules - modules if imported, would imply that the feature is enabled. Further could perhaps be detection of things like the class keyword when Object::Pad is in scope. I think between these three options, that should cover well over 99% of all the code you're likely to see in practice. And of that remaining 1%, it could likely be fixed into one of those options already covered.

[EvanCarroll]

except by changing to use an entirely different syntax (i.e. square signatures) which isn't happening.

...

Yeah - this is a slightly concerning one. It is of course far too late

....

It's not clear to me why that's the case. The reason why experimental is still there is presumably so you can go back and fix that. Certainly if there is no other way to accomplish this, it's preferable not to leave the language broken forever, to emit warnings on experimental signatures v1, and to release a version of signatures v2 which fixes this. I would prefer PPI work than having to change 1000 lines in the code base that I could find with,

rg 'sub [^{]*\([^)]' -t perl -g '!*.t' .

The tooling problems can be worked around, but it's nicer to have them actually fixed even with short term discomfort, imho. And that is the zeitgeist of what the community seems to want anyway. BREAK ALL THE THINGS, perl7() or die

[Grinnz]

I'm not sure what you're suggesting. The only way the signatures feature could be statically distinguishable from prototypes, as I said, is if its syntax is changed, which means you need to change all your code - there is nothing any breaking change could do to fix this without changing the syntax, because the syntax being indistinguishable is the problem. PPI has other options.

[EvanCarroll]

I'm not sure what you're suggesting. The only way the signatures feature could be statically distinguishable [...] is if its syntax is changed

I'm saying, your conclusion that it's too late to change the syntax for a better implementation when the feature is marked as experimental is not one I would endorse. The disclaimer for the experimental pragma was always there and it doesn't expire at any time,

Disclaimer Because of the nature of the features it enables, forward compatibility can not be guaranteed in any way.

I would prefer the feature represent the best of perl before it's committed. I would rather have static analysis enable a better version PPI, Perl::Critic, and Universal Ctags. I would say that the feature is experimental should reduce this conversation to,

• Is this feature reasonably the best we could do at this moment, without any regard for backwards compatibility with experimental features?

If you're answering, "no, we obviously made a mistake and should have chosen a different syntax" then I would support changing trajectory. It's not too late.

[leonerd]

As a mildy amusing side-note, sub :lvalue was introduced in 5.6 (March 2000) and declared "experimental" (before the warning category existed) right up until 5.20 stablised it in May 2014 - a total of 14 years. signatures hasn't even reached half of that yet ;) (see also https://twitter.com/cpan_pevans/status/1359486312416428032)

[nichtich]

After the disaster with smartmatch operator I don't trust any experimental features. You never know whether your code will run on current Perl without warning in the future. Moreover it's several lines of boilerplate (instead of one line with the Perl version number) to use it now. As long as signatures are experimental, the statement "Perl does not support method signatures by default" is true, and this is one (tiny) reason against using Perl.

[khwilliamson]

Can this be closed?

[wchristian]

Regarding the mentioned PPI issues, we now have a proof-of-concept: https://github.com/Perl-Critic/PPI/pull/280

[wchristian]

Above proof-of-concept is progressing, and feedback from anyone with some round tuits would be much appreciated.

[demerphq]

On Mon, 26 Dec 2022 at 11:54, Christian Walde (Mithaldu) < @.***> wrote:

Above proof-of-concept is progressing, and feedback from anyone with some round tuits would be much appreciated.

Could you be a bit more explicit about what help you need?

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[wchristian]

Could you be a bit more explicit about what help you need?

The issue is an implementation of a feature. That usually consists of creating high level semantics, naming api bits, implementing api changes, implementing documentation, implementing the underlying functionality. I have tried to note in various ways, as noted in the issue, where and how i implemented them. I would be glad if people looked at them to see if they can spot things i fucked up before my fuck-ups go live, or can suggest ways to improve things beyond what the todo list already notes. Speaking of the todo list it also has open questions that are merely a question of information gathering, which i don't expect anyone to be doing, but would also appreciate.

[garu]

As we all know, signatures are no longer experimental as of perl 5.36.0 (released ~1 year ago), so I think it is safe to close this issue.