The term "side effect" has a more specific meaning when talking about language constructs. You appear to be using the more general English meaning(s) of "side effect", which certainly isn't a good strategy for communication when surrounded by people using the programming-languages-specific term of art.
The term originates from talking about places where you can use an expression but some expressions can have side effects. The main "effect" of an expression is the computed value. A side effect of the expression would be the changing of some persistent storage (changing the value of a variable whose lifetime extends beyond the life of the expression, writing I/O, reading I/O and thus changing the seek position in some stream, etc.).
Now, considering just an assignment, it seems weird to refer to the actual assigning as a "side effect", as you noted. However, that is still what the technical term means. For example, a pure functional language doesn't allow side effects and thus has no such things as assignments.
Now, map and grep accept expressions which determine how they act. And there are several ways to get an assignment included in such an expression (use the BLOCK-without-comma syntax, use do { }, call a sub, etc.). The return value is the part of such an expression that is important to map or grep. The assigning of a value to a non-temporary variable is what the term of art "side effect" means.
So, yes, if just using the "plain English" term "side effect", you can look at an assignment inside of map/grep either way. But when talking about programming, using the term as you have tried to is mostly good for causing confusion.
- tye
In reply to Re^7: map in void context ("side effect")
by tye
in thread map in void context
by dharanivasan
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |