Live data from Hacker News

Having fun with Go's nil, interfaces and errors

katcipis.github.io

51–52 of 52 posts

Re: Having fun with Go's nil, interfaces and errors

#51
post #49

Earlier quoted context omitted.

The ability to call a method on a nil receiver doesn't have anything to do with what comparisons should do. Semantically, the question is whether == should compare the values or the vtables. In no other language I know of does it compare vtables.

Interface comparisons check both, the value and the dynamic type. Describing that as "comparing vtables" is misleading. It the types don't match, the operands are not considered equal. Type and value have to match for two interface values to be equal. How does that not make sense? For mismatched dynamic types you can't meaningfully compare the values in the general case, so of course you need to consider types.

> Type and value have to match for two interface values to be equal. How does that not make sense?

Because people expect == to compare values, not types. Nobody has ever questioned this behavior in Java and C#.

Re: Having fun with Go's nil, interfaces and errors

#52
post #50
post #43

Earlier quoted context omitted.

Couldn't they also be equal to each other? If equality was defined only in terms of the value and not the vtable (to borrow pcwalton's terms), they would be equal. Are there any problems which would arise from this?

Equality is not necessarily defined for values of different types ("with different vtables", if you will). You can't just compare values of different type and expect a meaningful result.

In this case, though, we're talking about interfaces; an interface is a pointer plus this bit we're calling a vtable. Pointers, even to different types, absolutely can be compared for equality, can't they? More specifically, i am pretty sure pointers can be compared to see if they are both nil, which is all that would be needed here.
Post reply on HN