5 ms·

item := item What does this do? That should be a no-op by default in any sane language.

_ikke_ 4y ago
The := both declares a new variable by an inferred type and assigns a value to it. Explicitly, this would be the same as var item *Item = item It creates a locally scoped variable that shadows the existing one.
- colonwqbang 4y ago
  Ah ok, so different name resolution rules apply on the left and right sides of the operator? On the left side, "item" resolves to the "item" in inner scope (that is declared on the same line). On the right side it resolves to the "item" in outer scope. Then I understand what's happening though I'm still not convinced it's sane behaviour. I would expect all identical names in a single scope to refer to the same variable.
  - deleted 4y ago
    [deleted]
ithkuil 4y ago
item = item That is a no-op a := b Declares a new variable a and assigns it. It's sugar for: var a = b So read it as: var item = item Many languages have scopes and variable shadowing. You can argue this is bad practice or whatever, but it's only confusing if you think := is assignment which is covered in the first page of the Go language tutorial.
- valenterry 4y ago
  Not a go dev, but var item = item should still be a noop imo. If it does some magic like dereferencing, make it explicit. And no, other languages making the same mistake is not a good excuse. Especially not for a language focused on inexperienced newgrads.
  - ithkuil 4y ago
    It introduces a new variable called "item" initialized with the value of another variable called "item" from the parent scope
    - Cthulhu_ 4y ago
      Exactly; the difference is in scope, the `item` in the range is scoped to the enclosing block, the `item` inside of the block is loop-block-scoped, shadowing the parent block. That said, it looks and feels dirty and buggy and it's a known workaround for a Go issue, so I'm glad they're at least talking about fixing it.
    - valenterry 4y ago
      What value does the first item contain (and what is its type)? What value does the second item contain (and what is its type)? What does the print function exactly do if I pass a variable to it.
      - ithkuil 4y ago
        I see your point. I think we're just using a different definition of "no-op". The statement by itself doesn't produce any visible side effect. However it creates a new logical variable in the abstract machine, and that can have real consequence in the real underlying machine, depending on which statements happen next. In particular, the new variable and the old variable are independent and thus the new variable may require to allocate some storage location (e.g. on the stack, a register, ...) to keep track of further mutations to its value (I say "may" because an optimising compiler may do without that extra location)
        valenterry 4y ago
        Yeah, so what my "problem" is is that in the code item := item item := item the two lines doing different things even though looking exactly the same. I'm a Scala dev and in Scala we have a similar thing, where a new import or definition in the middle of the code can change line semantics between two equal lines. But the difference is that this is not a mistake but a concious design to switch "contexts" and is heavily guarded by the typesystem, where GOs typesystem is incredibly weak in comparison, which is not an inherent drawback, but here it is. I do feel that I'll stick to my feelings that this design is confusing and should have been avoided from the beginning. Ku udos to the go team for breaking compatibility here. This is necessary for a language to not become another COBOL.
- colonwqbang 4y ago
  The thing which surprised me was not the variable shadowing, rather that the name "item" resovles to different variables on the left and right sides of the :=. This is unusual language design, most languages assign a single meaning to each name in each scope.
  - int_19h 4y ago
    It's unusual for the C-style family, but very common in functional languages outside of it, such as the ML family. It's not uncommon to see repeated lines of the form: let x = ... x ... and every such line is a declaration of a new variable that shadows the preceding one.
    - colonwqbang 4y ago
      Not in Haskell at least. What ML language are you thinking of?
      - int_19h 4y ago
        I had OCaml in mind, but this is perfectly legal Haskell, too: let x = 0 in let x = x + 1 in ...
        ithkuil 4y ago
        fwiw i've also seen this in Rust quite often: let foo = foo.clone(); let bar = bar.into_inner(); let baz = baz.to_owned(); let quz = quz.unwrap(); ...
ZiiS 4y ago
This is the declaration operator not assignment. It would not look like a no-op even if it isn't completly clear. It is creating a variable you control vs one that the loop controls and changes in ways you may not expect.
kweingar 4y ago
I suppose I’ve never programmed in a sane language then
rob74 4y ago
I guess that sane language would be Pascal, where := is the assignment operator (and = tests for equality, like you would expect if your brain hadn't been molded by generations of C-family languages). In Go, I guess having := is a nod to Pascal, but it declares a variable besides assigning it.
- tialaramex 4y ago
  One interesting thing several modern languages did was to decide that := is actually two separate tokens where : separates an optional type and = separates an initializer, so that my_goose : Goose = get_a_goose(); ... lets us give my_goose an explicit type, while we can write: my_goose := get_a_goose(); ... and leave the compiler to infer that my_goose is a Goose because that's what get_a_goose() returns and we didn't specify. The idea here is that we have this flexibility but we didn't burden the language with what feels like an extra feature (like C++ auto) with its own special rules. Given that := starts out as a single token this is in some sense revisionist, but so long as you're trying to learn to program, not studying the history of programming, that's fine. It reminds me of how eggcorns can become language features. A person incorrectly analyses a word or phrase they've heard, e.g. they think the things which fall off an oak tree must be named "eggcorns" because they look a bit like eggs. They apply this analysis, and, if the results are successful and out-competes existing correct analysis, it can dominate, next thing you know† your spelling correction tool says "Did you mean eggcorn?" when you type acorn. † In reality these transitions usually take generations https://en.wikipedia.org/wiki/Eggcorn https://en.wikipedia.org/wiki/Eggcorn
Blikkentrekker 4y ago
It is a non op; it's a matter of scope and is resolved entirely statically. One shadows the variable by a variable of the same name. The key is that the new variable is scoped only to the inside of the loop, whereas the original variable is scoped to the outside of it, thus assigning to the original variable in a next iteration of the loop updates that variable again. The major case where this is an issue is if one somehow took a reference to the variable, that reference thus now points to the new value rather than the old. Taking a reference to the new, more closely scoped variable that is local to the iteration of the loop does not have this problem.

The := both declares a new variable by an inferred type and assigns a value to it. Explicitly, this would be the same as var item *Item = item It creates a locally scoped variable that shadows the existing one.

colonwqbang 4y ago
Ah ok, so different name resolution rules apply on the left and right sides of the operator? On the left side, "item" resolves to the "item" in inner scope (that is declared on the same line). On the right side it resolves to the "item" in outer scope. Then I understand what's happening though I'm still not convinced it's sane behaviour. I would expect all identical names in a single scope to refer to the same variable.
- deleted 4y ago
  [deleted]

ithkuil 4y ago

item = item That is a no-op a := b Declares a new variable a and assigns it. It's sugar for: var a = b So read it as: var item = item Many languages have scopes and variable shadowing. You can argue this is bad practice or whatever, but it's only confusing if you think := is assignment which is covered in the first page of the Go language tutorial.

valenterry 4y ago
Not a go dev, but var item = item should still be a noop imo. If it does some magic like dereferencing, make it explicit. And no, other languages making the same mistake is not a good excuse. Especially not for a language focused on inexperienced newgrads.
- ithkuil 4y ago
  It introduces a new variable called "item" initialized with the value of another variable called "item" from the parent scope
  - Cthulhu_ 4y ago
    Exactly; the difference is in scope, the `item` in the range is scoped to the enclosing block, the `item` inside of the block is loop-block-scoped, shadowing the parent block. That said, it looks and feels dirty and buggy and it's a known workaround for a Go issue, so I'm glad they're at least talking about fixing it.
  - valenterry 4y ago
    What value does the first item contain (and what is its type)? What value does the second item contain (and what is its type)? What does the print function exactly do if I pass a variable to it.
    - ithkuil 4y ago
      I see your point. I think we're just using a different definition of "no-op". The statement by itself doesn't produce any visible side effect. However it creates a new logical variable in the abstract machine, and that can have real consequence in the real underlying machine, depending on which statements happen next. In particular, the new variable and the old variable are independent and thus the new variable may require to allocate some storage location (e.g. on the stack, a register, ...) to keep track of further mutations to its value (I say "may" because an optimising compiler may do without that extra location)
      - valenterry 4y ago
        Yeah, so what my "problem" is is that in the code item := item item := item the two lines doing different things even though looking exactly the same. I'm a Scala dev and in Scala we have a similar thing, where a new import or definition in the middle of the code can change line semantics between two equal lines. But the difference is that this is not a mistake but a concious design to switch "contexts" and is heavily guarded by the typesystem, where GOs typesystem is incredibly weak in comparison, which is not an inherent drawback, but here it is. I do feel that I'll stick to my feelings that this design is confusing and should have been avoided from the beginning. Ku udos to the go team for breaking compatibility here. This is necessary for a language to not become another COBOL.
colonwqbang 4y ago
The thing which surprised me was not the variable shadowing, rather that the name "item" resovles to different variables on the left and right sides of the :=. This is unusual language design, most languages assign a single meaning to each name in each scope.
- int_19h 4y ago
  It's unusual for the C-style family, but very common in functional languages outside of it, such as the ML family. It's not uncommon to see repeated lines of the form: let x = ... x ... and every such line is a declaration of a new variable that shadows the preceding one.
  - colonwqbang 4y ago
    Not in Haskell at least. What ML language are you thinking of?
    - int_19h 4y ago
      I had OCaml in mind, but this is perfectly legal Haskell, too: let x = 0 in let x = x + 1 in ...
      - ithkuil 4y ago
        fwiw i've also seen this in Rust quite often: let foo = foo.clone(); let bar = bar.into_inner(); let baz = baz.to_owned(); let quz = quz.unwrap(); ...

ZiiS 4y ago

This is the declaration operator not assignment. It would not look like a no-op even if it isn't completly clear. It is creating a variable you control vs one that the loop controls and changes in ways you may not expect.

kweingar 4y ago

I suppose I’ve never programmed in a sane language then

rob74 4y ago

I guess that sane language would be Pascal, where := is the assignment operator (and = tests for equality, like you would expect if your brain hadn't been molded by generations of C-family languages). In Go, I guess having := is a nod to Pascal, but it declares a variable besides assigning it.

tialaramex 4y ago
One interesting thing several modern languages did was to decide that := is actually two separate tokens where : separates an optional type and = separates an initializer, so that my_goose : Goose = get_a_goose(); ... lets us give my_goose an explicit type, while we can write: my_goose := get_a_goose(); ... and leave the compiler to infer that my_goose is a Goose because that's what get_a_goose() returns and we didn't specify. The idea here is that we have this flexibility but we didn't burden the language with what feels like an extra feature (like C++ auto) with its own special rules. Given that := starts out as a single token this is in some sense revisionist, but so long as you're trying to learn to program, not studying the history of programming, that's fine. It reminds me of how eggcorns can become language features. A person incorrectly analyses a word or phrase they've heard, e.g. they think the things which fall off an oak tree must be named "eggcorns" because they look a bit like eggs. They apply this analysis, and, if the results are successful and out-competes existing correct analysis, it can dominate, next thing you know† your spelling correction tool says "Did you mean eggcorn?" when you type acorn. † In reality these transitions usually take generations https://en.wikipedia.org/wiki/Eggcorn https://en.wikipedia.org/wiki/Eggcorn

Blikkentrekker 4y ago

It is a non op; it's a matter of scope and is resolved entirely statically. One shadows the variable by a variable of the same name. The key is that the new variable is scoped only to the inside of the loop, whereas the original variable is scoped to the outside of it, thus assigning to the original variable in a next iteration of the loop updates that variable again. The major case where this is an issue is if one somehow took a reference to the variable, that reference thus now points to the new value rather than the old. Taking a reference to the new, more closely scoped variable that is local to the iteration of the loop does not have this problem.