5 ms·

Everyone here is talking about that it's it the specification. If that's the case, and it does seem to be, then the problem is with the specification. Inconsis

Everyone here is talking about that it's it the specification. If that's the case, and it does seem to be, then the problem is with the specification. Inconsistent behavior is nasty at the best of times, and this is no exception. I can easily see bugs coming out of this. It's like C and undefined behavior. (Null checks in the linux kernel, anyone?) Even the best developers get bitten by it occasionally. It's one more subtle thing to remember, and everyone can only remember so much.

SamReidHughes 11y ago
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.
- 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 ago
    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.
- TheLoneWolfling 11y ago
  And you could say the same about null checks in C. And yet bugs of that sort still appear, up to and including in the linux kernel.
  - SamReidHughes 11y ago
    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.
    - Dylan16807 11y ago
      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.
      - SamReidHughes 11y ago
        It's not a "strawman" when you're arguing with the logic somebody else has presented to you.
        Dylan16807 11y ago
        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.
        SamReidHughes 11y ago
        It's not a similar situation.
        Dylan16807 11y ago
        That's an opinion, not a fact. Some people call it similar.

SamReidHughes 11y ago

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.

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 ago
  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.
TheLoneWolfling 11y ago
And you could say the same about null checks in C. And yet bugs of that sort still appear, up to and including in the linux kernel.
- SamReidHughes 11y ago
  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.
  - Dylan16807 11y ago
    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.
    - SamReidHughes 11y ago
      It's not a "strawman" when you're arguing with the logic somebody else has presented to you.
      - Dylan16807 11y ago
        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.
        SamReidHughes 11y ago
        It's not a similar situation.
        Dylan16807 11y ago
        That's an opinion, not a fact. Some people call it similar.