Sure, but passing by value isn't always realistic. If you have a hashtable with a million entries, you can't copy it just to update a value.
There's also the problem of internal mutation of state, with hashtables/collections being again primary examples. It's not always avoidable to have internal mutation, but it shouldn't be the default, in most cases it's just wrong.
That's a weird corner case... I wouldn't expect the compiler to keep me from shooting myself in the foot like that. I'm surprised that some people do expect it.
What do you honestly expect me to answer? That's kind of a moot point: the entire reason we have type systems in the first place is that they are partial, machine-checkable proofs of correctness. The entire discussion is how to strike the best power/practicality balance while keeping the thing decidable. Keeping you from shooting yourself in the foot is exactly the type system's job.
Why do you even bother with static types if you seriously believe that?
I believe in type systems as a way of knowing how data is encoded in memory. I don't expect them to somehow prevent me from writing that memory location more than once.
> Sure, but passing by value isn't always realistic. If you have a hashtable with a million entries, you can't copy it just to update a value.
What else are you going to do? If you want to insert a value but also have access to the hashtable without the change, then you need to copy it. (Or use a data structure with history tracking, like RCU or finger trees.)
If you don't need the old value, then you can optimize out the copy - this isn't too hard.
