> Making the change through assignment won't tell you what in the object changed either.
So encapsulation is preserved.
> Why would one write a function that takes an object, creates a copy of it, changes that copy, and returns the copy?
Because correctness is more important than efficiency. People maintain code, therefore to improve the likelihood that code changes are correct you trade off efficiency. What's the point of a super-fast algorithm if it gets the answer wrong.
If you really need that performance in a profiled chunk of code, references are still there, just not the default. You know what you're getting into.
In addition, for a high-level language, just because it has pass-by-value semantics doesn't mean it's doing copying under the hood. As I mentioned earlier, it's trivial to determine if a basic block will modify a variable. Why should a programmer waste time worrying about a detail that a compiler is guaranteed to get correct (unlike the person)?
And last, with NUMA architecture, actual copying will eventually become a performance advantage. You want to keep data you're modifying local to your processor, otherwise RFOs will kill any chance at near-linear scaling with cores.
> I could do the same (as a reference) with:
Yes, but what if you start with the second. You're faced with the following code:
x = 1
foo( x )
bar( x )
baz( x )What is the value of x at the end? Is it safe to reorder the calls? If you have this:
x = 1
foo_x = foo( x )
bar( foo_x )
baz( foo_x )You know the following at the end: