3 ms·
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
by VanillaCafe 11y ago
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.
- deleted 11y ago[deleted]
- SamReidHughes 11y agoThe 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.