[Enhancement] Allow names for anonymous subroutines.

[KES777]

Description
When code has many ANON subs it becomes nightmare to debug that code. Code traces becomes not so useful.

There are many workarounds exists for the issue:
https://www.perlmonks.org/?node_id=304883
https://www.masteringperl.org/2014/02/naming-anonymous-subroutines/
https://metacpan.org/pod/Sub::Util#set_subname

Steps to Reproduce

sub{ die "Here" }->();

This will show something like "died at main::ANON line 1".

Expected behavior
I am not sure what is the technical issue to not have this elegant solution:

sub name{ die "Here" }->();

OR:

my $x = sub name{ die "Here" }; $x->();

Which will show "name" instead of "__ ANON__" for dumped stack frames.

The difference with the regular subroutines will be that it will not be available through STASH and only affects names in frames returned by the call to caller.

at the moment both variants are "syntax error".

[tonycoz]

It sounds like you want lexical subs, they have names, they don't appear in the stash:

$ perl -MCarp -MDevel::Peek -e 'my sub x { confess "Foo" }; Dump(*x); my sub z { x(); } z()'
SV = PVGV(0x55e988029770) at 0x55e987f5e930
  REFCNT = 2
  FLAGS = (MULTI)
  NAME = "x"
  NAMELEN = 1
  GvSTASH = 0x55e987f33548      "main"
  FLAGS = 0x2
  GP = 0x55e98802ce90
    SV = 0x0
    REFCNT = 1
    IO = 0x0
    FORM = 0x0  
    AV = 0x0
    HV = 0x0
    CV = 0x0
    CVGEN = 0x0
    GPFLAGS = 0x0 ()
    LINE = 1
    FILE = "-e"
    EGV = 0x55e987f5e930        "x"
Foo at -e line 1.
        x() called at -e line 1
        z() called at -e line 1

Unfortunately you can't immediately invoke them nor use the definition as a value the way you can anonymous subs (no my sub x { ... }->(params) nor 'my $x = my sub x { ... }`)

[leonerd]

Traditionally this has been a usecase for Sub::Util::set_subname or the newer equivalents in meta:

use Sub::Util qw( set_subname );
my $thing = set_subname thing => sub { ... };

Now, $thing is a CODE ref that stores that name.

I'm also pondering a :name attribute for a variety of purposes such as this.

use v5.xx;
my $thing = sub :name(thing) { ... };

[KES777]

@tonycoz I see the next code works:

perl -e 'my $x = my $z = 3; print ">>$x<<"'
>>3<<

But my + sub for some reason does not return CODE:

perl -e '(my sub xx{ print "YES" })->()';
syntax error at -e line 1, near "(my sub xx"

Here I expect that my will return CODE to xx.

@leonerd solution also looks elegant.

But why in Perl we can allow to write my $x = sub name{ die "Here" };? (Is there technical issue to restrict that??)

The rule is very simple:

1. sub name {} defined in void context --> make sub available via STASH
2. my sub name {} --> makes sub available lexically
3. If sub name {} or my sub name {} were defined in SCALAR context --> additionally will return CODE
4. sub {} --> assign __ ANON__ to CODE and return it
5. my sub {} --> syntax error

Or: when sub was defined create CODE. If name was given assign it and make sub available via STASH or lexically (depending on presence of my) or assign __ANON__. Return CODE if sub was defined no void context.

[guest20]

There are two subs:

• the one that creates a code ref: my $x= sub {...}, similar to my $x = \*some_existing_sub;
• the one that declares a named sub ... sub xx {...}, which is pretty much this boi: *xx{CODE} = sub {...}

by mixing the two you are asking for two assignments in one place:

my $x= *xx{CODE} = sub {...}

It feels pretty clear then that this:

my $thing = sub with_name { ... };

... looks like an single assignment, but has the somewhat unusual side effect of also jamming that sub into the symbol table.

If you are thinking about how the language looks/acts while you're using it, this suggestion also changes the way code-refs are called, since $thing->() now has to behave like it's a regular call to with_name() except now the code that gets called isn't with_name, but rather it stays as the code-ref assigned to $thing, even after *with_name{CODE} is over-written by another code-ref.

So now I can't trust the sub name in a stack trace, because it could be masked by these Also known as names, which means that REF in the stack trace now needs to be replaced with something even more descriptive/upsetting to explain that you're calling a code-ref pretending to be with_name, instead of the with_name you see in the symbol table, maybe something like:

CODE(0xbadc0ffee) masking as with_name called at 23993.pl line 8 ...