# pure function in C

There does not seem to be a canonical definition of "pure function", but the widespread language-agnostic understanding seems to be a function that

• has no side effects
• produces a value that is completely and uniquely determined by its explicit arguments

This appears to beg a question when the arguments are themselves mutable, especially if they are passed by the value of a reference. To take one example, suppose I pass an array x to a function in C -- say it sums an array of int. For thinking about the purity of the function, how am I supposed to understand what has been passed? If I have a C understanding of it (forgive me for errors; I don't really speak C) then I have just passed a pointer, and whatever happens to be pointed to is a side-effect of the runtime behavior of the program. Yet for any given array of int, the function behaves in a fully predictable way, which seems pretty pure. So can a C function take an array as an argument and still be pure? (I want a language-agnostic answer, not a reference to the gcc docs.)

• If pointer argument is declared as "pointer to constant", then the function can be pure in the sense you described – HEKTO Jul 19 '18 at 2:19
• 1. Why do you think that what is pointed to is a side effect of the program? A side effect is a change to mutable, globally-shared state that is visible to other parts of the code (other than through the return value of the function). I think the obvious definition would require that the return value depend only on the values transitively reachable from the arguments; and that the function not modify any of those values (no observable side effects). 2. Related: cs.stackexchange.com/q/24406/755. – D.W. Jul 19 '18 at 2:26

When you pass a pointer (or an array, which decays to a pointer) in C, the exact details don't matter for function purity. What really matters is that you're given a way to access the object. This is the same as when any object is passed to a function in Java or Python.

There's no one correct universal definition of function purity, but ignoring these implementation details seems the most sensible: a function taking a pointer can be pure, as long as it doesn't mutate the object pointed to. In C, this can even be ensured, by making the argument a "pointer to const": this is what happens by default when you pass a double-quoted string (that is, a const char *, a reference to an immutable array of characters).

• This is the view I've leaned towards as well, but I remain uncertain about it. Purity of a function is supposed to mean that the value it returns depends only on the values of its explicit arguments. If I pass a pointer to a mutable type, then this is clearly untrue as a literal statement. (Which is why in gcc "a function that has pointer arguments and examines the data pointed to must not be declared const".) So the question is close to the question, how close is the proper language-agnostic understanding of a "pure function" to this notion of a "const function"? – Alan Jul 19 '18 at 13:28
• @Alan I'd say a "const function" is an implementation detail. Basically, the compiler can't guarantee you're writing pure functions if pointers are involved. But the compiler/interpreter can never guarantee that in a language like Python where all objects are passed by reference, and yet you can still do pure/functional programming in Python. – Draconis Jul 19 '18 at 17:18
• That begs the question, which remains (in your example) whether a function in Python can be pure if it consumer mutable objects. In order to answer that question, we need a language-agnostic definition of "pure function". I am looking for a way to go beyond opinions to underlying concepts of purity. (I.e., picking nits is the whole point of this question.) I had always taken the view you espouse until someone recently raised doubts; now I am plagued by doubts. Clearly the substantive point is important, whether or not any canonical use of 'pure function' deals with it. – Alan Jul 19 '18 at 17:28
• @Alan If we want to be picky, a C function taking a const int pointer might not be pure if there's a running parallel thread which changes the pointed-to data, making (say) *p + *p == 5 satisfiable. That could also happen if the C function invokes some callback (through a function pointer). Or we could even claim that even a pure function has the "side effect" of advancing the system clock, draining the battery, producing some heat, and potentially trigger GC (in some languages). Pragmatically, we want to neglect those effects in a hypothetical definition of "pure". – chi Apr 13 '19 at 8:38
• @Alan You might also want to read The C language is purely functional, which quite provoking, and toys with the definition of "pure" a lot. – chi Apr 13 '19 at 8:41

C and Python these are not the purely pure functional programming languages. But you could expect to write functions with much less side effect as far I know :) something is better than nothing in the context of C python, etc which are not purely functional programming platform. For more, you could read this article about a purely functional algorithm in a non-purely functional language like python http://scottlobdell.me/2016/02/purely-functional-red-black-trees-python/

comments are welcome for further discussion.

• I don't see how this answers the question. This site is a bit different from other sites you might be used to; we're a question-and-answer site, not a discussion forum, and we have strict quality standards. In particular, the 'Your Answer' box should only be used for material that directly answers the question at the top; not for other discussion or related remarks. Also, this site isn't intended for discussion, so a call for further discussion isn't really appropriate here. – D.W. Apr 13 '19 at 6:39