3 ms·

I haven't read much at all about Dart yet so forgive me if I'm missing something but it seems to me that dynamic-typing capabilities do not rule out absence-of-

by ericbb 15y ago

I haven't read much at all about Dart yet so forgive me if I'm missing something but it seems to me that dynamic-typing capabilities do not rule out absence-of-null. Doesn't Dart's use of optional typing mean that it really behaves as a statically-typed language in some contexts? The Go language sort of has this via interface types. Consider the following: type Foo struct { a, b int } func Bar(x interface{}) Foo { if f, ok := x.(Foo); ok { return f // x is a Foo at runtime so return it } return Foo{0, 1} } There is no need for the Foo type to have a null value. Go does have general zero-values for all types but that's somewhat different from null and not the only solution either. I think a Haskell-like model (neither null nor zero-value) could also work.

rayiner 15y ago
Dart never really behaves like a statically-typed language. Take this code: http://try-dart-lang.appspot.com/s/bA0X http://try-dart-lang.appspot.com/s/bA0X It not only doesn't give an error, but it runs just fine. main() passes "cake" to bar(), which passes "cake3" to foo(), because String overloads the + operator to coerce its RHS to a string before concatenating. foo() ends up receiving a string despite being declared as receiving a number, but does what one would expect because '+' is defined for strings as well as numbers. The compiler does not complain because it does not try to unify types globally. It does not care that bar(), which is declared as taking any type then passes that to foo() which is declared as taking a number. If you change the 'var' in the declaration of bar() to 'num' you will indeed get a type error in main() when it tries to pass bar() a string. So making types non-nullable in Dart would have little utility. Dart can't statically ensure that a variable declared as 'num' doesn't end up being a 'String' at run time, much less ensure that a variable is non-null. I don't see this as a weakness of Dart. The point of Dart's optional types is to enforce some structure, provide documentation, and avoid obvious mistakes in an otherwise dynamically typed language. Statically enforcing invariants like non-nulity is really beyond its scope.

by ericbb 15y ago

rayiner 15y ago

Dart never really behaves like a statically-typed language. Take this code: http://try-dart-lang.appspot.com/s/bA0X http://try-dart-lang.appspot.com/s/bA0X It not only doesn't give an error, but it runs just fine. main() passes "cake" to bar(), which passes "cake3" to foo(), because String overloads the + operator to coerce its RHS to a string before concatenating. foo() ends up receiving a string despite being declared as receiving a number, but does what one would expect because '+' is defined for strings as well as numbers. The compiler does not complain because it does not try to unify types globally. It does not care that bar(), which is declared as taking any type then passes that to foo() which is declared as taking a number. If you change the 'var' in the declaration of bar() to 'num' you will indeed get a type error in main() when it tries to pass bar() a string. So making types non-nullable in Dart would have little utility. Dart can't statically ensure that a variable declared as 'num' doesn't end up being a 'String' at run time, much less ensure that a variable is non-null. I don't see this as a weakness of Dart. The point of Dart's optional types is to enforce some structure, provide documentation, and avoid obvious mistakes in an otherwise dynamically typed language. Statically enforcing invariants like non-nulity is really beyond its scope.