The following program might be of interest:

#!/usr/bin/perl

use strict;
use warnings;

my ($a, @a) = ("");

sub foo : lvalue {
    print wantarray ? "LIST:   " : "SCALAR: ";
          wantarray ?  @a        :  $a
}

 foo ()   = 1; print "\$a = $a; \@a = [@a]\n";
(foo ())  = 2; print "\$a = $a; \@a = [@a]\n";
 foo ()  += 3; print "\$a = $a; \@a = [@a]\n";
(foo ()) += 4; print "\$a = $a; \@a = [@a]\n";

__END__
SCALAR: $a = 1; @a = []
LIST:   $a = 1; @a = [2]
SCALAR: $a = 4; @a = [2]
SCALAR: $a = 8; @a = [2]
[download]

Abigail

my %hash = ('a'=>1, 'b'=>1, 'c'=>1);
@hash{'a'..'c'} = 2;
[download]

This has the effect of assigning 2 to $hash{'c'}. ...the last element in the slice.

$VAR1 = {
          'a' => 2,
          'b' => undef,
          'c' => undef
        };
[download]

Code used for testing:

my %hash = ('a'=>1, 'b'=>1, 'c'=>1);
@hash{'a'..'c'} = 2;
use Data::Dumper;
print Dumper  \%hash;

%hash = ('a'=>1, 'b'=>1, 'c'=>1);
($hash{'a'}, $hash{'b'}, $hash{'c'}) = 2;
print Dumper  \%hash;
[download]

That means there's no C-style comma operator in Perl 6. If you want the last value of a list, subscript it with [-1]. This also means that a slice in scalar context will not return the last value as it does in Perl 5. If you try that in Perl 6, you'll get a list reference, which will fail when you try to apply a scalar operator like += to it. (Perl 6 has a way to apply scalar operators to lists, but you have to be explicit.)

I remember seeing some discussion about replacing the c-style comma operator with a keyword that achieved a similar effect. Various option where discussed -- also & then were muted I think.

Was any conclusion reached as a) whether there would be such a keyword? b) What it is likely to be?

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Timing (and a little luck) are everything!

Was any conclusion reached as a) whether there would be such a keyword?

Not by me. :-)

b) What it is likely to be?

I suspect a pop should be made to do the expected thing, in which case you have your keyword (or at least, method name). But as I said, a [-1] subscript will certainly work. It may well become the idiom of choice for when you really do want to select the last value.

But note that many uses of the C-style comma operator are in fact in void context, in which case you don't much care whether it returns the last value or a reference to the list, since it's just going to throw it away anyway. So you can just use comma in those cases.

I cannot remember any discussion to replace the C-style comma in the 7 years that I've read p5p. I don't think such a proposal would make any chance, for several reasons: there is already a synonym for the comma: =>; it doesn't save anything, instead of a single keystroke, you'd have to use at least 4, but often 5. And it has the potential to break existing code.

The comma is a well-known construct - especially amongst the people on p5p, as they tend to know C quite well.

Abigail

I think you are prying about the weedy backlots of perl syntax. Afaik, the is nothing in the perl grammar that says this should happen.

[Open Challenge]
Your mission, should you choose to accept it, Friar Monk, is go sourcediving into toke.c with the purpose of discovering what cosmic accident produces this behavior.

I think most of your trouble is with context. += and ++ give their operands scalar context, = only gives context to the right operand, based on what is on the left.

Secondly you're misrepresenting the defined behaviour of comma in scalar context. It isn't that comma acts that way, it is that lists act that way and comma normally delimits lists. Unless precedence gets in the way as in @foo = 1, 2; which is parsed (@foo = 1), $bar = 2;

Of course when you later look at +=, the same list behaviour shows up on the left hand side, resulting in the last element in the list being incremented.

The hash slice behaviour is all, of course, undefined since the order of keys is arbitrary (even more so in recent Perls).

The exact warnings that you get from various situations are, however, more likely to change from version to version.

UPDATE: Oops, ysth is (of course) correct. My bad.

The hash slice behaviour is all, of course, undefined since the order of keys is arbitrary (even more so in recent Perls).

Slices are always in the order in which you specify the keys.

Secondly you're misrepresenting the defined behaviour of comma in scalar context. It isn't that comma acts that way, it is that lists act that way and comma normally delimits lists

I'm inclined to respectfully disagree here. According to perlop, "Binary "," is the comma operator. In scalar context it evaluates its left argument, throws that value away, then evaluates its right argument and returns that value. This is just like C's comma operator. " I feel like this is a better way to think about it, since it's consistent with the doctrine of "there's no such thing as a list in scalar context."