Your RFC says:
> Currently, operators applied to lists in a list context behave
> counter-intuitively:
Counter-intuitively is different from consistently. Your title is
misleading. Perl's ops *are* applied consistently: they consistently
give their arguments scalar context (except for the short-circuiting
logops, which I'd like to fix by making them return the useful lists
instead of possibly a list or a scalar).
> The proposal to handle functions is tricky, since there is currently no
> obvious way to see whether a function is going to return a list. Either we
> need some kind of more advanced prototyping (or other way of creating a
> signature), or we need to manually change functions provided with Perl to
> check for list context and Do The Right Thing.
I assume you're talking about:
@r = func1() + func2();
If so, this isn't a problem. This code would result in func1 and
func2 being called in list context. You've got an addition in list
context (thanks to the assignment), and that would put func1() and
func2() into list context.
+ wouldn't look to its arguments to decide what to do. + would look
at its context. This would make it behave like reverse().
Note that this context inheritance confuses the bejaysus out of
people, c.f. the bugreports on
print reverse("is broken");
I did try to come up with some counter-examples, some code where this
new behaviour would make hard something that's currently easy. The
fact that list context is only really surprising in function calls
eliminated most of them. The objection I thought I had:
$matrix_size = @across * @down;
isn't valid because $matrix_size would dictate the current behaviour
for @across and @down. However:
print "You'll need ", @across*@down, " cells.\n";
would break.
Can anyone else think of existing code that would break?
Nat
