PrePPC - named parameters in signatures

[Paul "LeoNerd" Evans]

Something I've written about a few times in various "what might come
next in Perl" talks, has been adding some kind of named parameter
support to subroutine signatures.

I now have an implementation as part of XS::Parse::Sublike, that I've
been using in a few places and seems to be fine:

https://metacpan.org/pod/Sublike::Extended#Named-parameters

How would folks feel about me writing this up into a real PPC document,
ideally with the aim of trying to get something in place in time for
5.40?

--
Paul "LeoNerd" Evans

leo...@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

[Scott Baker]

I like this idea in theory, it’s come up several times now.

I'm a little unclear how doing this at the core subroutine level is different/better than just doing it with a hash:

sub color($x) {
    my $red   = $x->{red}   // 0;
    my $green = $x->{green} // 0;
    my $blue  = $x->{blue}  // 0;
    ...
}

That syntax has worked forever. If it’s in core we could enforce defaults and types easier I suppose, but I don’t know if that’s a big enough benefit.

- scottchiefbaker

[Paul "LeoNerd" Evans]

On Thu, 18 Jan 2024 15:03:10 -0800
Scott Baker <sc...@perturb.org> wrote:

> I'm a little unclear how doing this at the core subroutine level is
> different/better than just doing it with a hash:

I think much the same reason as signatures in general - it's the sort
of code you write lots and lots of, and it'd be nice if core provided
better support for the boring repetative parts of it.

However - that said, I also found I wanted to use parts of the same
idea in Object::Pad's `ADJUST` blocks for being able to name additional
construction-time parameters, so it may be that we'll want to reuse the
syntax in core's class feature ADJUST blocks as well.

[Martijn Lievaart via perl5-porters]

Op 19-01-2024 om 00:03 schreef Scott Baker:

I like this idea in theory, it’s come up several times now.

I'm a little unclear how doing this at the core subroutine level is different/better than just doing it with a hash:

sub color($x) {
    my $red   = $x->{red}   // 0;
    my $green = $x->{green} // 0;
    my $blue  = $x->{blue}  // 0;
    ...
}

That syntax has worked forever. If it’s in core we could enforce defaults and types easier I suppose, but I don’t know if that’s a big enough benefit.

It does, and it works, but it gets very tedious.

sub color($x) {
    my $red   = delete $x->{red}   // die "Missing red value";
    my $green = delete $x->{green} // die "Missing green value";
    my $blue  = delete $x->{blue}  // die "Missing blue value";
    if ($x->%*) { die "Unknown parameters ...."; }
    ...
}

As opposed to simply

sub color(:$red, :$green, :$blue) {
    ...
}

I know what I prefer.

HTH,
M4