Talk:Side effect (computer science)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.


In the future, this article should live at side effect (computer science)...

Yes. The medical meaning is by far the most prominent. --Tarquin

Functions without side-effects are idempotent?[edit]

I was thinking; are functions without side-effects per definition idempotent? If so; would it be worth mentioning idempotence in this article? --EdSchouten 14:14, 18 March 2006 (UTC)

No. Idempotence means it has the same effect whether used once or multiple times. Functions without side effects should have no side effect at all. --Spoon! 04:35, 22 October 2006 (UTC)
Functions without side-effects are not automatically idempotent. Consider a method written to return a random number. You call Random() and it has no side effects, it just returns one random number as designed. But it is not idempotent since every time you call it you will get a different return value --Lys1123 17:54, 01 October 2015 (UTC)
@Lys1123:. Returning a psuedo-random number requires updating the seed, or otherwise the same random number would be generated on the next invocation to Random(). Updating state is a side effect. Returning a truly random number requires accessing a hardware random number generator or other random number source. This is also a side effect. —Ruud 18:26, 1 October 2015 (UTC)
The initial definition in the article says that a side effect must be observable, not sure that this is the case with a hardware random number generator. (talk) 23:25, 31 March 2016 (UTC)

side-effects are also I/O[edit]

I think side effects are not just state, they are also I/O. More generally, any effect besides returning a value is a side-effect. Ideogram 19:27, 28 May 2006 (UTC)

not just functions[edit]

This article should not concentrate on functions; the concept extends to the evaluation of any expression. For instance, in C, the expression "x++" is side-effecting, as is the expression "getc(stdin)". — brighterorange (talk) 17:17, 16 June 2006 (UTC)

Wouldn't x++ be better listed as an example of a destructive update? --maru (talk) contribs 01:15, 21 June 2006 (UTC)

Explicit asignement is not a side effect[edit]

the article states that, in imperative programming, side effects make program work, however, if I'm not wrong, imperative programs can (or must) perfectly work without any side effects at all, by using just explicit asignement sentences ¿ isn't it ?

I think so, but the article says imperative programming often uses side effects, not that it must use them to work at all. --Gwern (contribs) 23:34 22 February 2007 (GMT)

Looping forever/diverging and call-by-value[edit]

Is looping forever/diverging a side effect? This article states that only changes in state can be side effects, but I've heard others say (possibly mistakenly) that looping forever/divering is a side effect.

Also, do the evaluations of function/operator arguments caused by call-by-value evaluation strategies count as side effects? What if the evaluation of an argument loops forever?

indil (talk) 23:19, 16 December 2008 (UTC)

There's no complete professional consensus, but many scholars and programmers consider divergence (nontermination) not to be an effect. I think it's because all you can observe is that either your program terminates or it hasn't yet, and if the program is going to diverge, changing the order of evaluation doesn't change what you can observe. Norman Ramsey (talk) 02:54, 20 April 2009 (UTC)

Removed "Safe operations are also idempotent, although the reverse is not necessarily true"[edit]

I removed the sentence: "Safe operations are also idempotent, although the reverse is not necessarily true" since it's not true.

There seems to be some confusion between side-effect-free and idempotent. As described on idempotent a function f is idempotent if forall x: f(x) = f(f(x)). An example of such an idempotent function is round, e.g. round(2.233)=2=round(round(2.233)).

This doesn't have anything to do with the round function being side-effect-free. E.g. if the round function increased a global counter each time it was called, then it would still be idempotent but not side-effect-free. A function like f(x):=x+1 is not idempotent but it is side-effect-free.

So side-effect-free <=> idempotent doesn't hold in any direction. Teglsbo (talk) 11:46, 23 January 2009 (UTC)

Focus! (and 'effects' versus 'side effects')[edit]

I've narrowed the focus of the opening considerably. The article is still a bit of a mess because 'side effect' is not really a technical term (though it's definitely a popular one). In the definition I have tried to make things more precise by using the well-defined notion of an effect. The original author seems to have conflated this idea with another idea (side effect) meaning perhaps 'effect that was not manifest in the source code' or 'effect I didn't want'. A better article would distinguish these two ideas, but I don't know how. Norman Ramsey (talk) 02:57, 20 April 2009 (UTC)

Propose removing the parts about machine instructions[edit]

The stuff about CPUs and pipelines, while interesting, seems superfluous to an article on side effects. And in 2009, pipelined machines are very old news, and pipeline bubbles are not interesting. I think the article would be stronger and more focused if that paragraph were removed. What do others think? —Preceding unsigned comment added by Norman Ramsey (talkcontribs) 03:06, 20 April 2009 (UTC)


Past history? Will shorten to history unless there are objections. —Preceding unsigned comment added by (talk) 10:06, 19 August 2009 (UTC)

Side effects vs. pure[edit]

Reading the definition in the current article I don't think it's obvious if a side effect free function is always pure.

The current definition is:

"In computer science, a function or expression is said to have a side effect if, in addition to producing a value, it also modifies some state or has an observable interaction with calling functions or the outside world."

Could interaction with the outside world be reading a global variable? The current article mentions "read data" as an example of a side effect.

In the section about Referential transparency a function is said to have referential transparency if it's side effect free and pure.

Pure is defined in a separate article as (my rephrasing): Independent of other inputs than given argument and side effect free.

But this article suggests that a side effect free function must not read data from the outside making pure and side effect free the same thing.

So my question is (which the article should make clear): Is today() from the pure function article side effect free? Teglsbo (talk) 21:24, 25 February 2010 (UTC)


I've added some examples to demonstrate how side effects work in C++ with the assignment operator. It's somewhat of a rehash of the information found on the operator associativity page (so a link may be all that's required -- delete code if desired), but it's a little more specific to side effects and their gotchas. (talk) 16:02, 7 November 2011 (UTC)

Is the definition given too restictive?[edit]

Might a method that returns no value, not also have a side effect? Take a method `DrawLine`, for instance, that outputs a line on the screen. If this methods writes something to a log file, wouldn't this be considered as being a side effect?

See also:

O. Jacot-Descombes (talk) 19:18, 1 January 2015 (UTC)

Sequential vs. Compositional idempotence example is confusing.[edit]

It is stated that:

   xSetter is not idempotent under function composition because xSetter(5) and xSetter(xSetter(5)) set x to different values where return value of xSetter is x; in this example return value is always 5.

However, it seems to me that `xSetter(xSetter(5))` is idempotent, since,

   xSetter(xSetter(5)) equals
   xSetter(5) equals

If I'm wrong, I'd still really like to see a better explanation in the article.

Hbogert (talk) 13:45, 16 May 2016 (UTC)