Making it clear a function can modify its parameters

Question

Why is it that so many programming languages make it possible for a function to modify an object passed to it as a parameter, without having some sort of syntax to make that clear to the caller. Eg consider:

SomeObject A(15), B
B = DoSomething(A)
print(A + " " + B + "\n)

Reading that code you would expect the output to be something like "15 75", ie A is what you constructed it to. However most languages make it possible for DoSomething to change the value of A. In C++ you can tell if its possible or not by looking at the declaration of DoSomething, eg by looking is the parameter is defined as a non const reference. However in many languages, such as Python there is really no way to tell without reading through the code for the function to make sure it never changes A.

Ive been bitten by this on a few occasions, especially when trying to work with someone else's code which uses this behaviour and usually results in going through the entire piece of code line by line to try and find what's changing the parameter...

Why is it that languages don't generally require some explicit syntax by the calling to say "yes this object can be modified", eg say "B = DoSomething(inout A)"?

Is there any codeing standards that help to prevent problems occurring, apart from the "never modify a parameter passed into the function"?

Answer 1

The "coding standards" vary by language and among users/teams. C++ has const-correctness, which when properly used counts as a coding standard. C# has out and ref parameters for obvious cases. I'd say the only real consistency across a wide range of languages is the fact that parameter modifications should always be documented in the post-conditions of the function.

Answer 2

If you look at Java, a method can not really change the parameter (Java has only input parameters). But the parameter is often just a reference to some object to work with, which means that the method can change the object in any possible way. This makes reasoning about the semantics (without looking at docs) hard, quite the opposite to function programming.

You are right that this is undesirable, but in the short term it made things easier. Unfortunately, most often it is short term what counts, so we are still working with languages that support hidden side effects...

Answer 3

This doesn't directly make your code-snippet more clear, but I want to mention it anyway: we're using a naming convention for the parameters to display exactly what you want. We use 'in', 'out' and 'io' prefixes. So the DoSomething declaration would look like DoSomething(ioSomeObject inA). When working in Visual Studio with Visual Assist you'll get a popup with the types and names of the parameters, and this documents possible side-effects. In my opinion this is more clear than documenting post-conditions.

Regards,

Sebastiaan

Answer 4

My preferred design pattern for this is immutable data classes.

With mutable classes, you have to think about whether it gets modified.

A point of clarification, by my understanding, Python is pass by value just like Java and C (without modifiers). But what you are passing is usually a mutable object.

(Edit: almost all mainstream languages follow these semantics now. The most prominent exception is Lisp, where you can not only modify mutable objects, but reassign the value pointed to by a variable.)