4 ms·

I agree that mutable-array covariance in a statically typed language is a Bad Idea (TM). But Dart's type checks at compile-time are so non-existent that array c

I agree that mutable-array covariance in a statically typed language is a Bad Idea (TM). But Dart's type checks at compile-time are so non-existent that array covariance is the least of my concerns. Take is simple example (you can run it on Dart's site [1]): applyShippingCost(num price) { return price + 10; } main() { print(applyShippingCost(100)); // Prints 110. Ok. var lol = "TROLOLO"; num thisIsNotANum = applyShippingCost(lol); // Nothing explodes here... print(thisIsNotANum); // Prints TROLOLO10, Yeahh B) } This runs well and compiles with no warnings. Types are not checked when assigning an untyped variable to a typed one, so while one would expect that type declarations should give us some form of type safety, they don't. As I see it, with Dart's optionally typed system you get the worst part of two worlds (if you opt to type your variables): having to declare the types of variables, as in a static type system (with no compiler type inference); and having no guarantee about those type declarations at runtime, as in a duck-typing type system. [1]: http://www.dartlang.org/ http://www.dartlang.org/

rayiner 15y ago
This is a function of pre-alpha tooling that doesn't do any type analysis. It would be trivial for the compiler to give you a warning in this circumstance with the type information you provided (and production compilers like SBCL will do so). That is ultimately the point of optional typing. To let you gradually firm up the types in your program as the design gels. The technology is there to get quite a lot of mileage out of the resulting type information, though I think it would definitely behoove Google to make sure the tooling works well from 1.0. E.g: https://gist.github.com/1325465 https://gist.github.com/1325465 In the declaim I've specified the type of fib to be integer => integer. In the test function, I define a local function that calls a library function to concatenate two constants. The test function then calls fib with the result of calling the local function. Compiling this, SBCL complains: https://gist.github.com/1325469 https://gist.github.com/1325469 Here, the compiler starts with the known types of "hello" and " world", realizes that the result of CONCATENATE must be an array or null (strings are arrays in Common Lisp), realize that the function FUN always returns a sequence, and then realize that this result conflicts with the asserted type of FIB. Indeed, if you define FIB inside TEST[1] you don't even need to declare the type of FIB, SBCL figures it out itself. [1] This restriction is a limitation of the semantics of Common Lisp. Global definitions could be redefined, so SBCL will not flow types through them. Lexical definitions cannot be redefined, so SBCL will analyze them. Dart does not have this limitation.

rayiner 15y ago

This is a function of pre-alpha tooling that doesn't do any type analysis. It would be trivial for the compiler to give you a warning in this circumstance with the type information you provided (and production compilers like SBCL will do so). That is ultimately the point of optional typing. To let you gradually firm up the types in your program as the design gels. The technology is there to get quite a lot of mileage out of the resulting type information, though I think it would definitely behoove Google to make sure the tooling works well from 1.0. E.g: https://gist.github.com/1325465 https://gist.github.com/1325465 In the declaim I've specified the type of fib to be integer => integer. In the test function, I define a local function that calls a library function to concatenate two constants. The test function then calls fib with the result of calling the local function. Compiling this, SBCL complains: https://gist.github.com/1325469 https://gist.github.com/1325469 Here, the compiler starts with the known types of "hello" and " world", realizes that the result of CONCATENATE must be an array or null (strings are arrays in Common Lisp), realize that the function FUN always returns a sequence, and then realize that this result conflicts with the asserted type of FIB. Indeed, if you define FIB inside TEST[1] you don't even need to declare the type of FIB, SBCL figures it out itself. [1] This restriction is a limitation of the semantics of Common Lisp. Global definitions could be redefined, so SBCL will not flow types through them. Lexical definitions cannot be redefined, so SBCL will analyze them. Dart does not have this limitation.