But this isn't surprising behavior and it's not edge case behavior either. It's exactly what the docs say will happen, and you don't even need to read the docs, it's exactly what you'd expect, given what the interface is and what that implies about how the feature could possibly be implemented.
That something is "expected" (for some definition of expected) doesn't mean the code is easy to reason about.
Initially, modifying "a" also modifies "b". Later, modifying "a" does not modify "b". I can't imagine a piece of code that uses "a" or b" that wouldn't care which of those two states the system is in.
And, knowing which of those two states code will be operating under will not be clear by simply looking at an arbitrary piece of code. The fact that it is well documented that transition may occur does not resolve this ambiguity.
The code in this example is very easy to reason about. Because it's a single function.
If it's hard to reason about two different handles of shared data where one of them is used to modify the shared data... don't do that. append is for operating on a slice that your code is using exclusively. Like in this example, where it's all in the same function and the behavior's predictable.
No, that's not a reasonable thing you're saying. That you can say foo about A and foo about B, the fact that saying foo about B is false does not imply that saying foo about A is false.
Strawman. The argument is that they are very similar situations with similar downsides and shoddy defenses. The argument is not that the defenses being wrong about C proves that they're wrong about Go.
That was not their logic. They were not depending on a fallacy. The comparison with C was not the basis of the argument. They were merely giving an example of a similar situation.
