Front page | perl.perl5.porters |
Postings from December 2019
Re: Query Parameters
Thread Previous
|
Thread Next
From:
hv
Date:
December 3, 2019 14:46
Subject:
Re: Query Parameters
Message ID:
201912031438.xB3EcNP00739@crypt.org
Dave Mitchell <davem@iabyn.com> wrote:
:On Fri, Nov 29, 2019 at 04:51:15PM +0000, hv@crypt.org wrote:
:> Dave Mitchell <davem@iabyn.com> wrote:
:> :=head2 Hash query parameter
:> :
:> :This is most useful in the presence of named parameters. [...]
:> :
:> :A hash query parameter can appear anywhere in the signature, including in
:> :amongst positional parameters, but in that case it is an error unless it
:> :is an even number of positional parameters before any first named
:> :parameter:
:> :
:> : sub foo($p1, ?%query, $p2, $p3, :$n1, :$n2) { ... } # ok
:> : sub foo($p1, $p2, ?%query, $p3, :$n1, :$n2) { ... } # compile-time err
:>
:> Maybe most useful, but not only useful in the presence of named parameters.
:> As such, it needs to allow for optional positionals. I think for this case
:> it should be defined explicitly _not_ to check parity, and silently include
:> a trailing undef if needed.
:
:So you mean something like:
:
: sub foo(?%all, $p1, $p2 = 0)
:
:?
Yes.
:
:My current intent would be:
:
:In the absence of any named params (or trailing hash slurpy), no runtime
:parity check is done on the args.
:
:If called as foo("a"), then %all becomes ("a", undef).
Good, that's what I would have hoped.
:What about
:
: sub foo(?%all, $p1, $p2, $p3 = 0)
:
:should that be a compile-time error or wok with an implicit undef 4th arg?
I think it should get an implicit undef if parity requires it: called with
two arguments, %all should have just one pair, and not an additional
(undef => undef) pair. I.e. it should behave the same as C< %all = @_ >.
Hugo
Thread Previous
|
Thread Next