Remove dynamic type

[maeddin]

Proposal

Dart should remove the dynamic type for stricter type-safety, better performance and less support for bad practices.

Justification

The use of dynamic is a bad practice, often even referred to as such in the documentation:

• "dynamic: Indicates that you want to disable static checking. Usually you should use Object or Object? instead." (https://dart.dev/language/built-in-types)
• "Dynamic calls are treated slightly different in every runtime environment and compiler, but most production modes (and even some development modes) have both compile size and runtime performance penalties associated with dynamic calls." (https://dart.dev/tools/linter-rules/avoid_dynamic_calls)

However, there are ways to bypass dynamic calls and implicit casts for your own projects using lints (e.g. with strong-mode).
But this does not solve the problems that the support for dynamic has for the Dart language in general.
Firstly, it results in worse performance of the compiled code, since more inefficient runtime checks are required. (I'm not an expert on Dart compilers, so correct me if I'm wrong on this point).
Secondly, the support of dynamic prevents other features that many developers would like to use in a type-safe object-oriented language. For example, private, protected and public modifiers are not possible because they could not support dynamic types except through very inefficient runtime checks (dart-lang/sdk#33383).

In general, Dart tries to be as type-safe as possible. But on the other hand there is this relict dynamic, which stands against it.
dynamic generally feels like a concession to JavaScript developers to get more of them to switch to Dart/Flutter. Developers who have moved from Java/Kotlin/Swift/C++,... are just disturbed by dynamic and it also doesn't bring any benefits except more opportunities to apply bad practices.

Impact

All code that currently uses dynamic would have to be changed to Object? or subtypes and implicit casts would be required. Also, method calls would no longer be possible without knowing the type of an object.

Mitigation

Since this would be a null-safety level change, it would have to be made optional at first and fully introduced with the next major release.

[lrhn]

This is a language change request. Moving it to the language repository.

[mateusfccp]

I don't use dynamic in ages. Everything can be written with Object? instead, except for maybe some sketchy edge-cases.

I see no downsides except for the fact that this is a very breaking change.

I fully support this change, but I find it hard to believe that the Dart team would go through this route, as they are pretty conservative about breaking changes.

[rrousselGit]

Same here. I've stopped using dynamic forever ago.

The only use-case I can think of today is mocking, which currently often relies on dynamic invocation with noSuchMethod.

There's also how dart:convert does a dynamic invocation of toJson

So removing it could be quite breaking. Although not impossible.
For instance, mockito already uses code-generation. So it could stop relying on dynamic altogether

[rubenferreira97]

I am also in favor of this change. As far as I know, the dynamic type introduces many edge cases to the language.
However, a question arises: Would removing the dynamic type from Dart pose a challenge for implementing interoperability with other languages, such as JavaScript?

[srawlins]

A stepping stone to removing dynamic from the language would be to ban dynamic calls in the recommended (or core) lint rule sets. You can upvote here: dart-lang/core#750 😁

[ykmnkmi]

I like it. I have been using strict type checks and explicit casting from the beginning using the Dart language.

[lrhn]

Is it the dynamic type existing, which is the problem, or its accidental use?

What if the only expression that could have type dynamic was e as dynamic, effectively making as dynamic a special syntactic form with special rules for member access and assignability, but dynamic couldn't otherwise be used as a type?
Then you can still ask for a dynamic invocation if you really need it, but it absolutely certainly cannot happen by accident, or because someone else chose dynamic for you.

Dynamism would then be an opt-in feature, with a clear syntactic marker everywhere it's used.
But you'd still have the power when you really need it.

The alternative is that there are existing features which cannot be retained. Like jsonEncode trying to call toJson, which is admittedly no great loss, but still an unmitigatable breaking change.

It might encourage introducing new, simple, interfaces and force existing code to implement those, in order for existing dynamic code to keep working.
Not sure having lots of small interfaces is a win. And without interface injection, it requires total cooperation.

(Not saying we cannot remove dynamic entirely, which I would have said before patterns, but it is a distinguishing feature of Dart that it is there, as a backdoor when what you want to do isn't something you can convince the type system of. Like late and as, ways to tell the static analysis that you do in fact know better. Which you better do then. But you're not asking to remove as, which is just as unsafe as dynamic, so I'll presume it's more about performance, and then just not using dynamic should be enough. Avoiding accidental use should put that within your own control.)

[mateusfccp]

What if the only expression that could have type dynamic was e as dynamic, effectively making as dynamic a special syntactic form with special rules for member access and assignability, but dynamic couldn't otherwise be used as a type?
Then you can still ask for a dynamic invocation if you really need it, but it absolutely certainly cannot happen by accident, or because someone else chose dynamic for you.

This would be better than what we have today and less breaking, so it may be an alternative path. From there we can think if it's really valuable to remove dynamic entirely.

But you're not asking to remove as, which is just as unsafe as dynamic, so I'll presume it's more about performance, and then just not using dynamic should be enough.

Honestly, I would also ask to remove as if we could improve our type system in the areas that today require us to use as. There are a few cases where I have to use as because I can't express what I want with the type system, and every single time I do this I become completely afraid of having runtime exceptions because I made something wrong. Yes, I am telling to the compiler that I know better, but the fact is that I am not 100% sure that I know better, it's only that I have no other way to to what I have to do.

[maeddin]

Is it the dynamic type existing, which is the problem, or its accidental use?

It is even the existence of dynamic for me, but through it, of course, the accidental use of it also.

What if the only expression that could have type dynamic was e as dynamic, effectively making as dynamic a special syntactic form with special rules for member access and assignability, but dynamic couldn't otherwise be used as a type? Then you can still ask for a dynamic invocation if you really need it, but it absolutely certainly cannot happen by accident, or because someone else chose dynamic for you.

Dynamism would then be an opt-in feature, with a clear syntactic marker everywhere it's used. But you'd still have the power when you really need it.

In my opinion, dynamic could be left optional in the language, as long as there is no performance loss for the language in general in the compiled code (so also e.g. for dart2wasm) if you don't use dynamic in it explicitly. Unfortunately, I cannot assess this, since I have little idea of the concrete implementation of the compilers.
If the compromises currently made for dynamic are too much, it should be removed completely. Because this way you could achieve not only clean code but also better native performance.

The alternative is that there are existing features which cannot be retained. Like jsonEncode trying to call toJson, which is admittedly no great loss, but still an unmitigatable breaking change.

It might encourage introducing new, simple, interfaces and force existing code to implement those, in order for existing dynamic code to keep working. Not sure having lots of small interfaces is a win. And without interface injection, it requires total cooperation.

For jsonEncode, you could either introduce a simple interface or have jsonEncode only support Maps, Lists, Strings, Numbers, etc. and you would have to call the toJson() methods of your own classes yourself before passing the result into jsonEncode. Either way, this wouldn't be the most drastic change (as you have already stated).
Too many small interfaces would of course be annoying, although you need at most one interface in most cases anyway. Besides, a lot of things (currently) are done by code generation, so for most use cases there would be no need for interfaces at all (unless I'm missing something here).
However, interfaces would be a compromise that can be made for compile time type checking. In the end, using interfaces is still cleaner than calling methods like toJson() through the dynamic type.

But you're not asking to remove as, which is just as unsafe as dynamic, so I'll presume it's more about performance, and then just not using dynamic should be enough. Avoiding accidental use should put that within your own control.

as should not be removed, because you actually need casts often. In Dart this happens implicitly most of the time, but the static analysis can't find everything, so sometimes you have to do it manually. And unlike dynamic, for using as you need to know the type, on which you want to call a method.