At the same time you claim the output is factual.
Please don't do this!!!
Point is that keys' prototype expects one %hash or @array not a scalar.
And the argument must start with % or @
DB<20> p prototype "CORE::keys" \[%@] DB<21> p keys @a DB<22> p keys %a DB<23> p keys $a Experimental keys on scalar is now forbidden at (eval 32)[c:/Strawberr +y/perl/lib/perl5db.pl:738] line 2. Type of arg 1 to keys must be hash or array (not scalar dereference) a +t (eval 32)[c:/Strawberry/perl/lib/perl5db.pl:\ 738] line 2, at EOF DB<24>
The point you should make is that there has to be exactly ONE argument!
That's why keys can't expect a LIST.
and this can't be changed with a new feature, because otherwise old code would break.
@all_keys = keys %h1, keys %h2;
which will parse like
@all_keys = keys(%h1), keys(%h2);
and collect the keys from %h1 and %h2
DB<26> %h1=(a=>1) DB<27> %h2=(b=>2) DB<28> x @all_keys = keys %h1, keys %h2 0 'a' 1 'b' DB<29>
Now, if keys LIST was allowed, than the first keys would try to consume the rest of the list.
@all_keys = keys( %h1, keys(%h2) );
That's why the idea of the OP can't be implemented, without breaking backwards compatibility!
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery
|Replies are listed 'Best First'.|
Re^11: Using 'keys' on a list (prototype & backwards compatibility)
by glycine (Sexton) on Jul 01, 2021 at 13:41 UTC