in reply to Strange aliasing(?) when modifying variable in range operator

> there's some logical explanation?

Well ... implementation details and an explicit warning not to mess with side-effects of multiple increments in the same statement.*

When calling a sub simple arguments are passed by reference which can be modified (you could call this alias) but the result of increments are passed as values .

The increments happen from left to right on the same instance, but will influence the aliases inside the sub.

DB<17> sub tst { say "@_" } DB<18> $i=0;tst $i,$i,++$i # last increment operates on fir +st two aliases 1 1 1 DB<19> $i=0;tst $i,$i,$i++ # again, increment returns value + at evaluation time 1 1 0 DB<20> $i=0;tst $i++,$i,$i++ # increments return value, but i +nfluence alias in the middle 0 2 1

Does it explain your results?

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

*) from perlop#Auto-increment-and-Auto-decrement

Note that just as in C, Perl doesn't define when the variable is incremented or decremented. You just know it will be done sometime before or after the value is returned. This also means that modifying a variable twice in the same statement will lead to undefined behavior. Avoid statements like:
$i = $i ++; print ++ $i + $i ++;
Perl will not guarantee what the result of the above statements is.

update

sorry I just notice that you didn't have multiple increments in the same statement,² but the explanation with call by reference and value still holds:

>perl -wE "$i=1; say for $i..$i++" # 2 .. 1 (first is alias +, postinc returns 1 ) >perl -wE "$i=1; say for $i..++$i" # 2 .. 2 (first is alias +, preinc returns 2 ) 2 ...

update

²) but already mixing $i and $i++ in the same statement is discouraged!

Replies are listed 'Best First'.
Re^2: Strange aliasing(?) when modifying variable in range operator
by vr (Curate) on Jun 09, 2018 at 18:01 UTC

    Thank you for answer, Lanx, but range operator is not a "call" (to function), is it? And operators aren't (shouldn't be(?)) executed before arguments are evaluated?

    Hm-m, I'm wrong. Back to school...

    >perl -wE "$i=1; say $i + ($i+=1)" 4
      You're welcome! :)

      NB: You have no guaranty at all when INSIDE the statement the increment happens, it's only guarantied AFTER the statement.

      Most probably is Perl doing internal optimizations here.

      Your do-block examples puzzle me, please note the difference between debugger and one-liner

      DB<1> $i=1; say for do{$i?$i:($i+1)}..$i++ #6 1 DB<2> q D:\Users\lanx>perl -wE "$i=1; say for do{$i?$i:($i+1)}..$i++ #6" D:\Users\lanx>

      again, unpredictable internal optimization.

      If interested, you could use B::Concise to track what is happening here...

      So Rule Of Thumb:

      NEVER mix $i and $i++ (or --$i) inside the same statement.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery