It's got nothing to do with operand evaluation order.

Who said anything about operand evaluation order? (How could there be an operand evaluation order for a unary operator.)

I'll come back to this.

It has to do with pre-increment returning lvalues.

$i = 0; ++$i = 'fred';;
Can't modify preincrement (++) in scalar assignment
[download]

So, not an lvalue.

is more or less equivalent to ... alias

Ah! That well know Perl keyword 'alias'....

It's got nothing to do with operand evaluation order.

Hm. "It" has everything to do with the fact that the evaluation order of sub-expressions is unspecified.

Where "it" is the contradictory and useless behaviour, observed by the OP, and repeated in my post.

Because, if were specified, then the implementation would not be able to get away with producing those totally illogical, useless results, for those unwise or unknowing enough to try and use, what could be a useful behaviour.

Your attempts to explain how the implementation produces these useless results from this unspecified and therefore deprecated code, does naught to detract from the reason why it has been possible to enshrine this broken behaviour in the implementation.

The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour. It is equivalent to C allowing:

#include <stdio.h>

void f( int *a, int *b ) {
    printf( "a: %d, b: %d \n", *a, *b );
    *a = 1;
    *b = 2;
}

int main( int argc, char ** argv ) {
    int x = 0;
    f( &( ++x ), &( ++x ) );
    return 0;
}
[download]

Which it doesn't:

junk.c
junk.c(11) : error C2102: '&' requires l-value
junk.c(11) : error C2102: '&' requires l-value
junk.c(11) : error C2198: 'f' : too few arguments for call
[download]

$i = 0; ++$i = 'fred';;
Can't modify preincrement (++) in scalar assignment
[download]


So, not an lvalue.

Hmm. I was looking at this prior to my previous post. Notice that:


do { my $i = 16; ${ \(++$i) } = 'fred'; $i };  # returns 'fred'

do { my $i = 16; ${ \($i++) } = 'fred'; $i };  # returns 17
[download]


Maybe the warning you got is due to how Perl parses the preincrement assignment expression? I don't know.

Waddayaknow! And I've even found a use for it:

print map ${ \( ++$i ) } %= 10, 1..30;;
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
[download]

Now all we've gotta do is document it, and we've a valid reason for it working that way: measuring golf games. Perfect :)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

Mind you, it might make explaining this one a tad awkward :)

$i = 0; print ++${\++$i}, 0+ ++$i, 0+ ++$i, ++${\++$i};;
6 3 4 6
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

Who said anything about operand evaluation order? (How could there be an operand evaluation order for a unary operator.)

You did, or rather the passage you quoted. The expressions whose order of evaluation is not defined are those that are operands. The order of those that aren't operands — those that are statements — is well defined.

No, the list operator is not a unary operator.

So, not an lvalue.

It appears that Perl doesn't realise that ++$i returns an lvalue (thus the syntax error), but it does.

$ perl -E'sub { $_[0]="fred"; }->($i++); say $i'
1

$ perl -E'sub { $_[0]="fred"; }->(++$i); say $i'
fred
[download]

Ah! That well know Perl keyword 'alias'....

You understood what that code did, right? Troll. It's actually an imported function, fyi.

"It" has everything to do with the fact that the evaluation order of sub-expressions is unspecified.

No, even if "it" was specified — it's currently left to right for all the operators involved — the results would be the same.

The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour.

That's entirely possible.

It is equivalent to C allowing:

Perl passes args by reference and C can't, so I don't see your point. It is equivalent to C++ allowing:

#include <stdio.h>

void f( int &a, int &b ) {
    printf( "a: %d, b: %d \n", a, b );
    a = 3;
    b = 4;
}

int main( int argc, char ** argv ) {
    int x = 0;
    f( ++x, ++x );
    printf( "x: %d \n", x );
    return 0;
}
[download]

Which it does:

$ g++ -o a a.cpp && a
a: 2, b: 2
x: 4
[download]

You did, or rather the passage you quoted. The expressions whose order of evaluation is not defined are those that are operands.

Okay. I see where you are coming from. You think that you know better what the authors of that passage meant when they wrote it, than they did. "They" being Kernighan & Ritchie in "Appendix A:The C reference Manual" of "The C Programming Language".

That explains a great deal.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour.

Note that this behaviour isn't unique to ++.

    sub f {say "@_"}
    my $n = 1;
    f $n += 2, $n += 2;
    __END__
    5 5
[download]

grep, values and lvalue subs also return lvalues. substr, pos and keys can also return lvalues.