Aha, I see. Thanks for explaining.
br. Chr.
lørdag den 25. juli 2020 kl. 10.56.35 UTC+2 skrev Jan Mercl:
> On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk
> wrote:
>
> > Is this something I should have deduced from the language spec?
>
> https://golang.org/ref/spec#Address_operators
>
> ""
On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk
wrote:
> Is this something I should have deduced from the language spec?
https://golang.org/ref/spec#Address_operators
For an operand x of type T, the address operation &x generates a
pointer of type *T to x. The operand must be addressa
You are probably thinking about code like this:
var f2 = *f1
Which will make a copy, although not because `f1` is dereferenced, but
because `=` was called on a value.
Dereferencing a pointer gives a reference to the same value, taking
address of the same value will produce a pointer to the same
On Sat, 2020-07-25 at 01:09 -0700, chri...@surlykke.dk wrote:
> &(*f1)
>
> would, first, create a copy of *f1, and then a pointer to that copy,
> but evidently f2 becomes a pointer to the same struct as f1. Is this
> something I should have deduced from the language spec?
&(*p) says "give me the
When running this program:
package main
import (
"fmt"
)
type Foo struct {
i int
}
func main() {
var f1 = &Foo{i: 0}
var f2 = &(*f1)
f2.i = 1
fmt.Println(f1, f2)
}
it yields:
&{1} &{1}
(https://play.golang.org/p/qKtURokUCEW)
I (naively) assumed that the expression
&(*f1)
would, first, c
