(Des-) ventajas de la tipificación estructural

Acabo de ver esta charla de Daniel Spiewak donde habla sobre las ventajas de la tipificación estructural en comparación con la tipificación nominal de Scala y Java . Un ejemplo de esta diferencia sería el siguiente código Java

public interface Foo {
  public int length();
}
public interface Bar {
  public int length();
}

Foo f = ...;
Bar b = f;

que por supuesto no se compilaría porque la compatibilidad de tipos entre Fooy Barestá determinada por el nombre.

Un sistema de tipos estructurales, por otro lado, podría declarar que ambos tipos son iguales o compatibles y, por lo tanto, entre otras cosas, permitiría la tipificación de pato comprobada.

Ahora creo que entiendo la mayoría de las ventajas de un sistema de tipo estructural, pero me pregunto si no invalidaría la seguridad de tipo de ejemplos como los siguientes

class Foo {
  class Bar { /* ... */ }
  def takeBar(b: Bar) = { /* ... */ }
  def getBar: Bar = new Bar
}

val foo1 = new Foo
val foo2 = new Foo
foo1.takeBar(foo1.getBar) // should compile
foo1.takeBar(foo2.getBar) // should not compile

¿Es correcto entender que en un sistema de tipo estructural la última línea también se compilaría y, de ser así, no sería una desventaja con respecto a la seguridad de tipo?

En realidad, los tipos dependientes de la ruta son ortogonales al tipo estructural frente al tipo nominal. No está realmente claro qué significa una clase interna en el contexto de un lenguaje estructuralmente simple. Sin embargo, es muy posible definir esto. Si tuviera que definir clases internas en un contexto estructuralmente tipado, necesitaría asegurarse de que los casos como el que enumeró serían rechazados (precisamente por las mismas razones que Scala los rechaza).

Rechazaría tales casos haciendo lo mismo que Scala: modelar el tipo dependiente de la ruta como un tipo existencial. Se mantendría el mismo procedimiento de empaque / desempaquetado que rodea el acceso a objetos, y los resultados se verían casi idénticos a lo que hace Scala. Los resultados pueden parecer una igualdad de tipo nominal, pero seguiría siendo un sistema de tipo estructural, ya que la cuestión de la compatibilidad de tipo aún se decidirá en la interfaz en lugar del nombre.

La tipificación estructural tiene muchas implicaciones, pero (quizás sorprendentemente) la mayoría de los mismos conceptos que todos conocemos y amamos de los sistemas de tipo nominal se trasladan a los estructurales. La tipificación estructural no es más que una forma diferente de definir la compatibilidad de tipos.

La tipificación estructural facilita la escritura de código genérico de biblioteca. La razón número 1 por la que el ecosistema de Java está tan hinchado es porque es difícil escribir bibliotecas pequeñas fácilmente. Si Java estuviera tipificado estructuralmente, creo que sería una historia diferente y una situación mucho mejor.

La única desventaja que se me ocurre para la tipificación estructural es la posibilidad de una compilación más lenta. No estoy seguro de si los lenguajes estructurales generalmente se compilan más lentamente que los nominativos o no, pero, por ejemplo, Golang tiene un tipo estructural y una compilación muy rápida.