4 ms·

This is not really a bug -- it's a natural consequence of supporting value semantics. The Go code var player Player otherPlayer := player otherPlayer.sc

This is not really a bug -- it's a natural consequence of supporting value semantics. The Go code var player Player otherPlayer := player otherPlayer.score = 0 has the exact same "bug." This isn't something that should be fixed by the language. Instead, a linter rule that detects that the write is never read would catch this.

tapirl 3y ago
The author didn't say it is a bug. The author just says this is a shortcoming of Go.
- coder543 3y ago
  > The author didn't say it is a bug. The author's title literally refers to it as a bug.
- Joker_vD 3y ago
  For reasons it’s never really bothered me, but the *other* loop bug does bite me some times. This is the one where the loop values are values. The common mistakes wiki lists the capture bug twice, but doesn’t mention this bug. Yeah, I guess you're right, the author didn't call it a bug...
  - tapirl 3y ago
    I believe the author doesn't mean it is a bug in the general sense. The author just means it is a shortcoming, and this shortcoming is surely fixable. The author provides a solution, but I think the zig way is better: for _, *player := range players { player.score = 0 }
    - lsaferite 3y ago
      If they meant 'shortcoming', they would have used that word. They used the word 'bug' to describe the issue. Repeatedly.
bobbylarrybobby 3y ago
Not to be the guy who brings Rust into the Go thread, but… Rust supports value semantics, and also supports `for player in &mut players { player.score = 0; }`.
- pjmlp 3y ago
  Likewise in other languages with similar value semantics, but as we know those are PhD features only relevant for folks playing with language research.
- tylerhou 3y ago
  It’s a natural consequence of value semantics and not supporting references / pointers with range syntax :). (You can still write the same bug in Rust or C++ accidentally.)
  - sapiogram 3y ago
    > You can still write the same bug in Rust I honestly don't think you can. If you try to iterate over values instead of references, you'll take ownership of the vector and not be able to use it again.
    - tylerhou 3y ago
      If the value is Copy, you will make a copy and won’t take ownership, right? (Iterate over a vector of ints). Granted Rust structs are not Copy by default. Same with any C++ class for which there is no copy constructor.
archargelod 3y ago
But why would Go even allow you to mutate the temporary variable? For example, in Nim (it also prefers value semantics) this would result in a compile error: var players = [1, 2, 3] for player in players: player = 0 Instead, you have to use the explicit `mitems` iterator, to get mutable references: var players = [1, 2, 3] for player in players.mitems: player = 0
- Joker_vD 3y ago
  > why would Go even allow you to mutate the temporary variable? Because it's a variable. That's what you do with variables, you mutate them to hold different values. There are no "named, non-constant holders for values that you can't mutate directly" in Go.

tapirl 3y ago

The author didn't say it is a bug. The author just says this is a shortcoming of Go.

coder543 3y ago
> The author didn't say it is a bug. The author's title literally refers to it as a bug.
Joker_vD 3y ago
For reasons it’s never really bothered me, but the *other* loop bug does bite me some times. This is the one where the loop values are values. The common mistakes wiki lists the capture bug twice, but doesn’t mention this bug. Yeah, I guess you're right, the author didn't call it a bug...
- tapirl 3y ago
  I believe the author doesn't mean it is a bug in the general sense. The author just means it is a shortcoming, and this shortcoming is surely fixable. The author provides a solution, but I think the zig way is better: for _, *player := range players { player.score = 0 }
  - lsaferite 3y ago
    If they meant 'shortcoming', they would have used that word. They used the word 'bug' to describe the issue. Repeatedly.

bobbylarrybobby 3y ago

Not to be the guy who brings Rust into the Go thread, but… Rust supports value semantics, and also supports `for player in &mut players { player.score = 0; }`.

pjmlp 3y ago
Likewise in other languages with similar value semantics, but as we know those are PhD features only relevant for folks playing with language research.
tylerhou 3y ago
It’s a natural consequence of value semantics and not supporting references / pointers with range syntax :). (You can still write the same bug in Rust or C++ accidentally.)
- sapiogram 3y ago
  > You can still write the same bug in Rust I honestly don't think you can. If you try to iterate over values instead of references, you'll take ownership of the vector and not be able to use it again.
  - tylerhou 3y ago
    If the value is Copy, you will make a copy and won’t take ownership, right? (Iterate over a vector of ints). Granted Rust structs are not Copy by default. Same with any C++ class for which there is no copy constructor.

archargelod 3y ago

But why would Go even allow you to mutate the temporary variable? For example, in Nim (it also prefers value semantics) this would result in a compile error: var players = [1, 2, 3] for player in players: player = 0 Instead, you have to use the explicit `mitems` iterator, to get mutable references: var players = [1, 2, 3] for player in players.mitems: player = 0

Joker_vD 3y ago
> why would Go even allow you to mutate the temporary variable? Because it's a variable. That's what you do with variables, you mutate them to hold different values. There are no "named, non-constant holders for values that you can't mutate directly" in Go.