develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Named argument syntax (was Re: PSC #049 2022-01-07)

Thread Previous | Thread Next
Dan Book
January 22, 2022 06:04
Re: Named argument syntax (was Re: PSC #049 2022-01-07)
Message ID:
On Sat, Jan 22, 2022 at 12:39 AM Darren Duncan <>

> On 2022-01-19 4:41 a.m., Dave Mitchell wrote:
> > 1) Another advantage of not populating @_ is that it removes a whole
> bunch
> > of edge cases concerning what happens if @_ is modified during arg
> > processing.  In particular things become more complicated if we ever
> > implement named args: this is where the caller does foo(y =>2, x =>1)  to
> > call sub foo(:$x, :$y) {} - here the processing of default args etc
> > doesn't follow a simple L-R ordering and it's more likely that @_ could
> > get modified mid-processing.
> I know this isn't the main point of what you're saying, but I want to
> address
> the matter of named arguments.
> Your example code using "=>" may have just been representative and not
> literal.
> But I want to argue that when/if Perl does add native support for named
> parameters/arguments, which I hope it does, I feel that we must use a NEW
> syntax
> to indicate it, and NOT use "=>".
> While Perl devs are used to "=>" to indicate fake named
> parameters/arguments,
> the fact remains that this is really just a "fat comma" and a lot of code
> is
> going to break if Perl starts saying that the syntax now maps to named
> parameters.
> I propose following an example which is very common in other languages and
> data
> formats, and is also better Huffman coded, which is to use the colon ":"
> to
> indicate named parameters or arguments.
> This shouldn't conflict with any other use of the colon that I'm aware of.
> So these two things should continue to have the same meaning, and map to 2
> positional parameters:
>    foo('x', 'y')
>    foo(x => 'y')
> ... and this would continue to map to a single positional parameter which
> is a
> hashref:
>    foo({x => 'y'})
> Whereas this would map to a named parameter:
>    foo(x: 'y')

It's certainly an interesting idea and I think similar to something that
has been proposed before (not specific to signatures), but for the specific
signature feature, consider that one might want to pass a set of named
parameters directly from aggregate data sources such as: foo(%params) - it
would be a shame to lose this ability as well.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About