[wredue]

I agree. Just letting you know that, most likely, the people you are learning about “side effects” from don’t actually mean “side effect” in the colloquial sense of “state changes beyond the expectation”.

They mean literally any change at all. If your function is named addOne(&x), then they consider the result of x being one greater to be a “side effect”, whereas I suspect actually sane people such as yourself would not see that as a side effect.

This type of definition fuckery is one reason (among many), that I’ve come to fully disrespect functional programming communities.

One thing that also needs to be understood is that side effects (to your definition) are not explicitly bad things. Side effects ignoring boundaries, ignoring APIs, holding references, etc are probably mostly bad though.

In fact, in gaming, providing hooks to empower side effects is often explicitly good for granting designers mechanic freedom.

[Gibbon1]

My belief is the people you are talking about think of programs as batch operations where you take data transform it and then pass it to someone else's API calls. In that case state is sort of evil.

In embedded and gaming state changes in response to input is the point of everything.

[mrkeen]

I'm one such person!

"Side effect" doesn't have any useful meaning if it doesn't have teeth.

Nothing is a side effect if it's what the programmer intended to do.