4 ms·

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 comp

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.

prodigal_erik 10y ago
If x.Foo() and y.Foo() do different things and return different values, clearly x != y, and golang needs some kind of SQL-style is-null check rather than using equality to check for null. But dynamic dispatch on "what type of object do I not have?" is still a damn weird thing to want.
Vendan 10y ago
Having dealt with languages that don't, I much prefer ones that do. The thing is, most languages DO basically check vtables, in that 2 values with different types will never be equal (unless there is implicit casting or some kind of equality override). For instance, 1 == "1" is valid, and true, in PHP, even though that is less then ideal. The difference, of course, is that most of those checks are done at compile time in many languages. Go will do some checks at compile time, but it's specifically unable to do some of them due to the "dynamics" of how interface variables work.
slrz 10y ago
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.
- pcwalton 10y ago
  > 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#.

4 ms·

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 comp

by pcwalton 10y ago

prodigal_erik 10y ago
If x.Foo() and y.Foo() do different things and return different values, clearly x != y, and golang needs some kind of SQL-style is-null check rather than using equality to check for null. But dynamic dispatch on "what type of object do I not have?" is still a damn weird thing to want.
Vendan 10y ago
Having dealt with languages that don't, I much prefer ones that do. The thing is, most languages DO basically check vtables, in that 2 values with different types will never be equal (unless there is implicit casting or some kind of equality override). For instance, 1 == "1" is valid, and true, in PHP, even though that is less then ideal. The difference, of course, is that most of those checks are done at compile time in many languages. Go will do some checks at compile time, but it's specifically unable to do some of them due to the "dynamics" of how interface variables work.
slrz 10y ago
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.
- pcwalton 10y ago
  > 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#.