Can't say I really dig using runtime type checks as a get out of jail system for harder to verify problems. The problem I have with that methodology is it crea

Can't say I really dig using runtime type checks as a get out of jail system for harder to verify problems. The problem I have with that methodology is it creates errors that could have otherwise been caught statically. Consider, for example, the given example let a: Int = 1 let b: Any = a let c: Int = b In this simple case, it seems like everything works fine. But what if instead of `b = a` we had `b = foo()`? Now all the sudden discovering whether or not `b` can be safely assigned to an `Int` depends entirely on what `Foo` returns. If foo returns `Any` then you can have a mess where some refactoring ends up having a hard to detect bug. Consider, for example if foo is changed from foo() { return 1 } to foo() { if(bar) return "a" else return 1 } That could be fine given foo is already sending back `Any` but now when `bar` is true that string returned could cause a runtime exception far from where `foo` was defined. To me, this seems like giving up a large portion of the benefits of having typing in the first place. Dart 1.0 had a similar system with "optional typing" which was ultimately axed because of issues like these [1]. In my view, this sort of type system is `Any` creating optional typing. [1] https://news.dartlang.org/2017/06/a-stronger-dart-for-everyone.html https://news.dartlang.org/2017/06/a-stronger-dart-for-everyo...