CODEWITHSUNDEEP
genericscovariancedarttype-systems
Pradeep
Pradeep

Reputation: 4127

why optional typing in Dart?

http://www.dartlang.org/docs/spec/dartLangSpec.pdf

The language spec for Dart mentions below

Dart supports optional typing based on interface types. The type system is unsound, due to the covariance of generic types. This is a deliberate choice (and undoubtedly controversial). Experience has shown that sound type rules for generics fly in the face of programmer intuition. It is ..

Upvotes: 7

Views: 2366

Answers (3)

munificent
munificent

Reputation: 12364

What was the Dart lang spec writers thinking when they say sound type rules for generics fly in the face of intuition?

Take a look at the related questions to the right of this one. I see:

  • Why is List<Number> not a sub-type of List<Object>?
  • Why generic interfaces are not co/contravariant by default?
  • Why can't I assign a List<Derived> to a List<Base>?
  • Why cant I cast from a list<MyClass> to List<object>?
  • Why Animals[] animals = new Cat[5] compiles, but List<Animal> animals = new List<Cat>() does not?

While covariance isn't sound (for many mutable types), it is the behavior that many programmers intuitively expect when they first start working with generic types.

Upvotes: 8

Alan Knight
Alan Knight

Reputation: 2971

More concretely, as far as unsoundness goes, generic types are covariant. So a List of Strings can be passed to something that expects a List of Object. This is not typesafe, because the thing that expects a list of Object could conceivably try to add something to the List which wasn't a String. But telling people that when you have B as a subclass of A, but Collection<B> is not a subtype of Collection<A> is quite non-intuitive.

Upvotes: 2

moraes
moraes

Reputation: 13629

From Gilad Bracha [1]:

You can write a tool that will scream bloody murder about these things, but what you can’t do is stop people from running their programs.

Or, in other words [2]:

The problem is that expressing type flow fully and explicitly is more difficult for most programmers than writing code that passes values around and deals with runtime type errors when and if they happen. The word chosen for this difference in difficulty is that the latter is more "intuitive" than the former - I don't think it's a particularly bad choice of word. The phenomenon is one of the biggest reasons dynamic languages have become a lot more popular over recent years, a rejection of complexity in specifying static types.

It's like there's another triangle tradeoff: expressive, sound, simple: choose any two for your type system. Almost everyone is unwilling to forgo expressiveness - the object graphs weaved in modern software can be quite tangled indeed - while any language that hopes to have large-scale success cannot start out being anything but fairly simple. So they give up some measure of (statically-typed) soundness, and expect lots of runtime type errors during debugging and testing.

[1] http://blog.sethladd.com/2011/11/transcription-of-quick-tour-of-dart-by.html

[2] http://lambda-the-ultimate.org/node/4377#comment-67589

Upvotes: 9

Related Questions