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. -DanThread Previous | Thread Next