Language with "dynamic" type can't be called "statically typed".
I argue static typing is the ability to static type up to 100% of a program, not the exclusion of a dynamic type.
Dart's types exist only on compilation step. You can try to use "strong mode" in theory, in practice you will never compile it with third-party libraries.
*const u32 const uint32_t *p
I'm not sure what you mean about trait names. The purpose of the Any trait is to make it possible to pass around values of any type and dynamically downcast them, as the documentation indicates. That is a safe analogue of casting a void pointer to another type.
fn example(foo: Any) -> u32 {
foo+55
}
It's the difference between dynamic language and language with synthetic type for reflections.
In any case, you're moving the goal post from "concrete type at compile time" to "can represent any type", which is inherently going to be specific to how the language defines types. This is not an especially useful type of dynamic representation so I'm not sure why it would be desirable.
Any talks about special traits in Rust are offtopic, while code I wrote as example can't be compiled in Rust and can perfectly work in Dart.
I wasn't trying to argue about words or terms, I was trying to say the gist: Dart has dynamic type, so you can send to your function any type and this function will just use it, without any downcasting - language will take care about it; and Rust doesn't have such type: you can't even compile code which is trying to work with variables like you can do in dynamic languages.
But then all of that useless arguing... It's really funny when I see how people are trying to prove that Rust has same dynamic type as Dart. The very nature of these languages is different.
let i: u32 = 1;
let p_imm: const u32 = &i;
Look at the const u32 in the type position.
The rust book even refers to const and mut pointers as types.
The rust book even refers to *const and *mut pointers as types. *const u32
The type system will infer a static type based on the type of the initializer.
In some cases, inference may fail to infer a type. Right now, that can silently give you dynamic, but there's a flag to make that an error. I expect before too long that will be the default behavior.
Dart's developers think otherwise[1]:
> Q. Is Dart a statically typed language?
> Yes, Dart 2 is statically typed. For more information, see Dart’s Type System.
> With its combination of static and runtime checks, Dart has a sound type system, which guarantees that an expression of one type cannot produce a value of another type. No surprises!
> Even with type-safe Dart, you can annotate any variable with dynamic if you need the flexibility of a dynamic language. The dynamic type itself is static, but can contain any type at runtime. Of course, that removes many of the benefits of a type-safe language for that variable.
[1] https://www.dartlang.org/faq#q-is-dart-a-statically-typed-la...
Do you personally use it? That "strong mode" is a theory-only thing, it doesn't work with any real code, only with code you wrote without real third-party libraries.
There is no option in Dart 2; everything is the equivalent of strong mode, which eliminates ecosystem problems.
Your claim was true several years ago, but since then the entire ecosystem has migrated onto the new strict type system. It was a monumental amount of work, but, thanks to lots of effort from our users, we're there.
Aside from a small number of more-or-less dead packages, you should be able to use any third-party Dart packages you want while still using the new type system.