On Sat, Oct 08, 2022 at 07:13:17PM +0200, Branislav Zahradník wrote: > Please differentiate between named argument function call syntax and named > parameter extended signatures. I think I covered that in my email from an hour ago. > What we should answer first is want we want: > - do we want to limit arguments to $ sigil (+ slurpy) ? Arguments are an arbitrary list passed to a function. It is up to the coder of that function how they precess those arguments, assign values to local variables, check for errors etc. They may use the traditional approach of directly accessing @_, or use the new signature feature to allow the perl internals to more efficiently do some of that processing in an automated fashion. > - do we want freedom of function user to choose how to call function? (for > examples functions in > Postgresql, C#, Kotlin, Python) I have no idea what any of those languages do. But in general, the perl philosophy is that a user can construct the arguments to a function however they chose: foo(1,2,3,4); @a = (2,3); foo (1, @a,4); foo((1,$cond ? (2,3) : (-2,-3)), 4); etc. And this would be unaffected by function's signature, which isn't examined by perl at the call site at compile-time, nor run-time. If you want something like that, then that's what prototypes are for. > - do we want extended constraints? (eg: $login and $oauth are mutually > exclusive, $password must be specified when $login exists) I've never considered constraints that affect more than a single parameter. I have no strong opinion on whether they would be a good idea or not. I would likely want to see some proposed syntax/semantics before forming an opinion, -- The crew of the Enterprise encounter an alien life form which is surprisingly neither humanoid nor made from pure energy. -- Things That Never Happen in "Star Trek" #22Thread Previous | Thread Next