Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
January 19, 2022 12:41
Subject:
Re: PSC #049 2022-01-07
Message ID:
YegHCCXSacWBY3IC@iabyn.com
On Sun, Jan 09, 2022 at 12:37:32PM +0000, Neil Bowers wrote:
> The topic we've discussed a lot recently is what to do with @_ in
> signatured-subs:
A few more facts I've just remembered to chuck on the fire.
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.
As well as confusing or undefined behaviour, it requires more arg
processing overhead, because for example the size of @_ needs to be
rechecked after each arg, in case it has shrunk or grown in the meantime.
2) Some miscellaneous behaviours we may want to pin down before making
signatures non-experimental.
a) we should more clearly document the ordering of side effects (such as
calling FETCH() on tied values), or more to the point, document what
things are officially undefined, giving us more flexibility to change
things later when optimising.
b) banning of goto's into and out of default blocks:
we currently warn when entering a block containing a default expression:
Use of "goto" to jump into a construct is deprecated at ...
Perhaps that should be upgraded to a fatal error.
Jumping into the main block of a sub from a default expression doesn't
currently warn - maybe this should become a fatal error?
sub foo2 ($x = do { goto MAIN }, $y = ...)
{
MAIN: print "in main body\n";
}
c) decide where whitespace is is allowed or forbidden: this is currently
legal:
sub foo ($ x) {}
I think it would be nice to make it a compile-time error.
d) should duplicate parameters be a compile error? (at the moment it just
warns):
sub f ($a,$a) { ... }
"my" variable $a masks earlier declaration in same scope
Having now remembered a bunch of stuff in addition to @_ which might effect
experimentality, I'm leaning more strongly towards:
5.36 - make use of @_ a compile-time warning;
- fix up the other stuff mentioned above if we have time.
5.38 -stop populating @_
- make signatures non-experimental if we feel confident, else defer
for 1 more release.
5.40+ add new signature features.
--
Modern art:
"That's easy, I could have done that!"
"Ah, but you didn't!"
Thread Previous
|
Thread Next