I do like lists, it is so much more flexible for passing parameters, easy to build optional parameters, etc. I just need always be concerned about scalar/list context in expressions, that's all.

I found japhy's article about scalar/list context, and it was real eye-opener, when I learned that

sub A {
    return ('a', 'b', 'c');
  }
$a = A();    # $a gets value 'c'
($b) = A();  # $b gets value 'a'
[download]

As japhy explains:
The A() function, in scalar context, has the comma operator act on the comma separated series of values, and so $a is set to 'c' which makes sense. $b, however, gets the value 'a', because it invokes list context on the function, which returns a list.

japhy: ++ for you!

pmas
To make errors is human. But to make million errors per second, you need a computer.

For me after I learned what context was I made the decision that in my code the callee was responsible for working in either list or scalar context, and then it was the caller's job to not play games with it. Having somewhere to place that responsibility has made consistent handling of it work out quite well.

But yes, this feature is one that Perl programmers far too often gloss over, and it is so key to the language that they are really missing something if they don't understand it.

Actually, () only very rarely denotes list context. I've been trying to figure out all of the possible ways to use () to create a list context and I have yet to come up with more than one: List assignment. (Perhaps I'm overlooking some?)

That is, taking a scalar assignment and adding parens around the left-hand side switches the right-hand side from scalar to list context. I can't come up with any other cases where parens change the context.

So the only change you'd need to require for Perl6 is a new syntax for list assignment. Since     [$a,$b]= @list; isn't already taken, that would work.

But, it is also true that you've misinterpretted the problem and made it to be much bigger than it really is. So perhaps the change isn't as necessary.

Actually, if we did make it so that (...)= no longer denoted a list assignment and so left the right-hand side in a scalar context, then we'd have new surprises because:      my( $a, $b )= ( 4, 5 ); would be interpretted as:      my $a; my $b= 5;

So I don't think you'll have much luck convincing Larry and Dominus to make that change.

But I have an idea for another change that might have a chance of getting accepted. How about an compile-time warning for:      ( $scalar )= EXPR that suggests that you either drop the parens or rewrite that as:      $scalar= ( EXPR )[0] depending on what you really meant?

Even that might be a bit of an up-hill fight as code like:     my( $arg )= shift; works just fine since shift returns a scalar. I don't know how easy it would be to generate the warning only if the right-hand side cared about its context...