All of this is what I'm working on, but I don't have a commit bit, so it's not going anywhere without getting thoroughly vetted and blessed first.

I'm posting my code at http://github.com/PeterMartini/perl, in the peter/signatures branch (meant to be kept in tandem with doy/subroutine-signatures).

GOAL:

Part 1:

In the scope of use feature "signatures" (or whatever)

sub foo($bar,$baz) {}
equivalent to sub foo { my ($bar, $baz) = @_; }
sub foo($bar,@baz) {}
equivalent to sub foo { my ($bar, @baz) = @_;}
sub foo($bar,%baz) {}
equivalent to sub foo { my ($bar, %baz) = @_;}

Part 2:

Add a *new* way to access this information. This does not replace prototype, and is not meant to. I'd vote for 'signature', either as a keyword or in some namespace (Scalar::Util?)

I haven't thought this one through yet, but the big concern will be making sure it doesn't block future growth.

Part 3:

For backwards compatability, add a proto attribute to allow for the old behavior.

sub foo($bar,$baz) : proto($$) {}
equivalent to sub foo($$) { my ($bar,$baz) = @_;}

I don't plan to protect this by a feature.

I don't care either way whether:

sub foo($$);
sub foo($$) : proto($$){}

is legal or not, but will allow it as long as all of the prototypes match.

Note that:

sub foo($$);
sub foo($bar,$baz) : proto($$) {}

MUST have a proto attribute, or it will die due to the prototype mismatch (prototype would be none)

Part 4:

In the check phase of compilation, implicitly convert:

sub foo { my ($bar, $baz) = @_;}

to (internally) sub foo($bar,$baz){}

If and only if the assignment is the first statement of the sub, the named variables are the first entries in the PAD (for technical reasons) and @_ is not modified.

SELECTED POINTS OF CONTENTION:

1. Q: What is the value, if its just saving keystrokes?
Possible A: It's wanted often enough that several CPAN variants exist
Possible A: It *may* improve performance
Possible A: It adds another method of introspection, allowing the code to formally declare its own parameters.

2. Q: Will this prevent custom CPAN modules from implementing their own syntax?
My A: No. The signature will be controlled by a feature, which means if a 3rd party module is used, it can simple shut off the built in signature.

3. Q: Should a named parameter list *be* the prototype (accessible through prototype(\&sub), though not necessarily affecting parsing)?
My A: For backwards compatibility reasons, no. The current prototype is a simple string; I think it may make much more sense to expose the signature information as a string an array of hashes (depending on wantarray / GIMME), to allow room for growth.

4. Q: Do we really want to create lexical variables without an explicit ‘my’?
My A: I originally allowed for an explicit my, but there seemed to be no other reasonable options so I'd dropped it as redundant.

5. Q: What about @_?
My A: At this stage, I have no intention of touching it. It will continue to be available for read-write access, and it is necessary if a sub wants to check the count of arguments it was passed (sub foo($bar) would have no way of seeing the second, third, etc argument)

I'm sure I missed plenty of questions and answers - I'll add them either here or in future posts as I spot them.