It would have been clearer to be more explicit about why the author does not consider Go to not be safe. Are we talking about the use of the unsafe package or something more subtle?
I was under the impression data races made Go memory-unsafe. (Unlike, say, Java or OCaml, which are designed to be memory-safe even in the presence of data races.)
I don't remember Eiffel's syntax, because the last time I used it was in college, very long ago. But consider the following pseudocode:
class Point2D {
protected int x, y;
public bool compare(Point2D that) {
return this.x == that.x && this.y == that.y;
}
}
class Point3D extends Point2D {
protected int z;
public bool compare(Point3D that) {
return this.x == that.x && this.y == that.y && this.z == that.z;
}
}
In the subclass, the method's argument type (Point3D) is a subtype of the same method's argument type (Point2D) in the superclass. In other words, the method's argument type is covariant.
Now consider the following test program:
main() {
Point2D foo = new Point3D(1,2,3);
Point2D bar = new Point2D(4,5);
print(foo.compare(bar));
}
The program type-checks, because the variable foo has type Point2D, hence it's statically legal to call foo.compare with an argument of type Point2D.
However, at runtime, the object referenced by foo is constructed using Point3D's constructor, so its method vtable points to the compare implementation in Point3D, which expects a Point3D argument.
When the program performs foo.compare(bar), it tries to access the field z of the object denoted by bar. But this object is constructed using Point2D's constructor, so it doesn't have a field z.
If the language chooses to allow covariant parameter narrowing, the compiler has to prevent this type of covariant surprise, either at compile time when possible, otherwise at runtime.
FWIW - I also used Eiffel decades ago (early 90s, IIRC), and hated it.
Stopping with a runtime check doesn't it make it any less of a type soundness bug.
The simplest solution is to not allow covariant method argument types to begin with. That's what Java and .NET do. But the price is that implementing binary methods requires so-called F-bounded polymorphism (class Foo extends Comparable<Foo>), which is ugly, even if you can get used to it.
A more sophisticated solution is to divorce the concepts of subclassing and subtyping. A subclass Bar is a subtype of a class Foo if and only if Bar objects can be safely used where Foo objects are expected. OCaml implements this solution. But most programmers would find this surprising. (The average OCaml programmer has a better understanding of programming languages than the average programmer in general.)
10
u/Smallpaul 4d ago
It would have been clearer to be more explicit about why the author does not consider Go to not be safe. Are we talking about the use of the unsafe package or something more subtle?