Front page | perl.perl5.porters |
Postings from January 2022
On Sat, Jan 22, 2022 at 12:39 AM Darren Duncan <darren@darrenduncan.net>
wrote:
> 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.
-Dan
Thread Previous
|
Thread Next