Creating an interface is not creating a pointer to a zero sized variable.
a==b prints false. That means, a and b point to different locations
Bar(a)==Bar(b) prints true. If a!=b, then Bar(a) must be different from Bar(b)
On Thu, Feb 22, 2024 at 9:15 AM Axel Wagner
<axel.wagner...@googlemail.com> wrote:
>
> If you expect that, you are misreading the spec. There is no guarantee of any
> behavior here. An implementation is allowed to flip a coin, every time you
> create a pointer to a zero-sized variable, and either return a unique pointer
> or a singleton. I think you may assume that &a == &a, always. But apart from
> that, who knows.
>
> Zero-sized variables *may* have the same address. They don't *have* to.
>
> On Thu, Feb 22, 2024 at 5:12 PM burak serdar <bser...@computer.org> wrote:
>>
>> On Thu, Feb 22, 2024 at 9:00 AM Axel Wagner
>> <axel.wagner...@googlemail.com> wrote:
>> >
>> > Note that in the Spec section I quoted above it says "Two distinct
>> > zero-size variables may have the same address in memory" (emphasis mine).
>> > There is no guarantee, that all zero-sized values have the same address
>> > (otherwise, you'd get into inefficiencies when taking the address of a
>> > zero-sized field in a larger struct, or when converting a zero-capacity
>> > slice into an array-pointer). But it is allowed.
>> > If you require two pointers returned from different code paths to be
>> > different, for correctness, then you have to make them point at something
>> > that has non-zero size. Otherwise, all potential combinations are valid
>> > according to the spec.
>>
>> Yes. But in that case, you'd expect either a==b and Bar(a)==Bar(b) to
>> be both true, or both false. In this case, one is true and the other
>> is not.
>>
>>
>> >
>> > On Thu, Feb 22, 2024 at 4:53 PM burak serdar <bser...@computer.org> wrote:
>> >>
>> >> The compiler can allocate the same address for empty structs, so I
>> >> actually expected a==b to be true, not false. However, there's
>> >> something more interesting going on here because:
>> >>
>> >> a := &Foo{}
>> >> b := &Foo{}
>> >> fmt.Printf("%t\n", *a == *b)
>> >> fmt.Printf("%t\n", a == b)
>> >> fmt.Printf("%p %p\n", a, b)
>> >> x := Bar(a)
>> >> y := Bar(b)
>> >> fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >> fmt.Printf("%t\n", x == y)
>> >>
>> >> Prints:
>> >>
>> >> true
>> >> true
>> >> 0x58e360 0x58e360 // Note that a and be are pointing to the same address
>> >> true
>> >> true
>> >>
>> >>
>> >> But:
>> >> a := &Foo{}
>> >> b := &Foo{}
>> >> fmt.Printf("%t\n", *a == *b)
>> >> fmt.Printf("%t\n", a == b)
>> >> //fmt.Printf("%p %p\n", a, b) // Comment out the print
>> >> x := Bar(a)
>> >> y := Bar(b)
>> >> fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >> fmt.Printf("%t\n", x == y)
>> >>
>> >>
>> >> Prints:
>> >>
>> >> true
>> >> false
>> >> true
>> >> true
>> >>
>> >>
>> >> On Thu, Feb 22, 2024 at 3:56 AM Brien Colwell <xcolw...@gmail.com> wrote:
>> >> >
>> >> > I'm confused by this output. It appears that the interface of two
>> >> > different pointers to an empty struct are equal. In all other cases,
>> >> > interface equality seems to be the pointer equality. What's going on in
>> >> > the empty struct case?
>> >> >
>> >> > ```
>> >> > package main
>> >> >
>> >> > import "fmt"
>> >> >
>> >> > type Foo struct {
>> >> > }
>> >> >
>> >> > func (self *Foo) Hello() {
>> >> > }
>> >> >
>> >> > type FooWithValue struct {
>> >> > A int
>> >> > }
>> >> >
>> >> > func (self *FooWithValue) Hello() {
>> >> > }
>> >> >
>> >> > type Bar interface {
>> >> > Hello()
>> >> > }
>> >> >
>> >> > func main() {
>> >> > a := &Foo{}
>> >> > b := &Foo{}
>> >> > fmt.Printf("%t\n", *a == *b)
>> >> > fmt.Printf("%t\n", a == b)
>> >> > fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >> >
>> >> > c := &FooWithValue{A: 1}
>> >> > d := &FooWithValue{A: 1}
>> >> > fmt.Printf("%t\n", *c == *d)
>> >> > fmt.Printf("%t\n", c == d)
>> >> > fmt.Printf("%t\n", Bar(c) == Bar(d))
>> >> > }
>> >> > ```
>> >> >
>> >> > Prints (emphasis added on the strange case):
>> >> >
>> >> > ```
>> >> > true
>> >> > false
>> >> > **true**
>> >> > true
>> >> > false
>> >> > false
>> >> > ```
>> >> >
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "golang-nuts" group.
>> >> > To unsubscribe from this group and stop receiving emails from it, send
>> >> > an email to golang-nuts+unsubscr...@googlegroups.com.
>> >> > To view this discussion on the web visit
>> >> > https://groups.google.com/d/msgid/golang-nuts/d93760c9-61a7-4a3c-9b5c-d89f023d2253n%40googlegroups.com.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "golang-nuts" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to golang-nuts+unsubscr...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqrq21ymUJ00ni_JV%3Dkv6itqZg51GoWM5zJNjcGU1BKcuA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqpAfYag3-vKL7-5EFQWPv85dOXo8ewHeO%3D7KYHHV-7w2w%40mail.gmail.com.
