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

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

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
October 12, 2022 11:33
Subject:
Re: Named argument syntax (was Re: PSC #049 2022-01-07)
Message ID:
Y0amDhaSHVn52aTL@iabyn.com
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" #22

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About