Which hot reload? (1) reloading the web page on change, (2) reloading the Dart source in the VM. For the later there is this: https://github.com/dart-lang/sdk/blob/master/runtime/vm/serv...
What makes you think there will even be a 2.0? I ask because a couple of years ago there was talk of 2.0, but sadly, that has tapered off to silence.
We've been quieter publicly than I'd prefer, but we've been no less busy for it. Stuff that's going on:
1. We have a giant corpus of internal code at Google that we support and migrating all of that to strong mode while also iterating on strong mode itself is a ton of work. (Very few languages significantly change their type system after launch!)
2. The new dev compiler that generates cleaner modular JS is maturing and getting an increasing number of internal users. There's a lot of features to add, bugs to iron out, etc.
3. We are consolidating our tools onto a shared front end (lexer, parser, static analyzer). Up until now, we've had independently written and maintained front ends for the VM (in C++), dart2js (in Dart), and the analyzer for IDE support (also in Dart, but a separate codebase). Merging those into a single shared front end is a monumental amount of work since each of those targets has very different needs and hard performance requirements.
Hopefully soon we can start saying more about what's coming.
We intend to work on it at a later point again.
Currently, we are not spending resources on parallel execution (with isolates), either. There are other easier features that have more impact.
Eventually, we will revisit this topic, and see if we can make things easier. Multithreading itself is extremely unlikely, but there are other ways we can make parallel execution better; for example with easier data sharing between isolates.
Which features?
- better type promotion (`if (x is! A) throw "not A"; useAsA(x);`.
- Optional new/const.
- Allowing named arguments at any position at the call site.
These are all easier to specify and implement, and reach more users.
I'd be happy to assist if you share details of what you are trying to achieve.
Any updates on that? Do you still think it's a go?
However, it's still on the list of features we would like to work on. Adding it later gets harder (because we don't want to break our users), but we hope that we can find a good migration path.
For example, the current promotion rules would handle:
test(String? string) {
if (string != null) {
print(string.length); // Know string is non-null here.
}
}
test(String? string) {
if (string == null) return;
print(string.length); // Don't know it's non-null here.
}
So right now, I'm working on getting that landed because it's a necessary precondition for non-nullable types and also improves the language even if we don't get NNBD.
Aside from that, I'm not working on it directly. Much of the team is very focused on unifying our various parsers and analyzer's so we're trying not to also throw a bunch of language changes at the same time.
I think everyone wants to do non-nullable types, but it's a big, difficult feature and the longer we wait, the harder it gets. I hope it's not too late, but we'll have to see.
In a second case, after checking value, type of variable does not changed.
// Vraible "string" still have a non-nullble type here // What problem you found here? // Non-nullble type cannot be null even only because analyzed code. print(string.length); // Don't know it's non-null here.
// This is dead code, if you don't know if (string == null) return;
I also would like to see Anonymous classes like in Java if it were possible.
No promises, of course, but that's something we're hoping to do soon.