I disagree. There are far too many ways in which this can fail to use it to convey information. If anything, the method name should make it clear whether it mutates the input, rather than rely on shady clues from the return type.
Consider these, rather common, failure modes (pardon the Java-esque style):
public Model copy(Model m)
The name implies the action - it just makes a copy (although fails to say if it's deep or shallow, if they differ in this case). It would be rather bad if you thought that this mutates the model and returns it, just on the basis of being used to your schema.
public Collection<Model> readInput(Input in)
This method has a proper signature and it's obvious what it's doing. There's a good chance it will mutate
in and will not be able to restore it to its original state (nor should it, really). If you're used to your method, you will totally misread what it's doing.
A possible "fix" would be to pass in a collection to append new models to, but then you have 2 mutated parameters.
Another "fix" is to have a local instance collection to use, but there's a myriad of reasons why that's a bad idea. I'll focus on 1 of them in particular: A fully read input stream is useless to return. There's literally nothing you can do with it, except close it. Most of the time, your output will be simply ignored.
I generally prefer
void methods when dealing with methods whose main goal is to mutate their parameters or local state. A
void method that does not mutate anything might as well be dead code (with the single exception of assertion methods that
throw). As such, if you see a
void method, you know that something will be mutated.
There is one good reason to return your mutated argument - that is making your API friendly to chaining. When you have reason to believe that the user will invoke multiple methods in a row, and there is nothing better to return, return the mutated input.
But whether you're chaining, copying, reading or consuming, the main idea is that the method signature should give you the relevant information on what it does and what side-effects it has. That will likely involve some amount of convention, but that's to be expected, really. The output will give some extra idea of how to use the result of the method, but not about what it does.