Lasse R.H. Nielsen

No real opinion on removing the behavior. Sure, go for it! The implementation looks potentially unsafe. If you disable stack chaining using this function, then start a new stack chaining...

One helping hand could be that the analyzer recognizes that you have a body of a void function with no side-effects. I don't know if the analyzer catches "useless operations"...

This is not something we are planning to change in the language right now. If we revisit `void` in the future, we might reassess that part as well, but that's...

I think we should fix it, by saying that `return;` is allowed if the function "may return no value", which we then define as a return type of `void` or...

This is currently working as specified. It's a bad user experience, so we should consider whether we *can* change it. It's likely non-trivial to define where the return type is...

You should use `return null;`. It's annoying, but currently required if your return type is not `void`, and `FutureOr` is not `void`. (It's somewhat hard to distinguish the types in...

Should that be *minimal*? I can do less! (Or more, with less. Or something.) Consider: * Some way to recognize metaprogramming annotations in a file. `@[...]` syntax is fine, and...

The reason we don't always promote is indeed that it may be confusing when the promoted type gets captured. ```dart num x; // ... if (case1) { x = 0.0;...

Whether we filter types of interest at the type-check point or the assignment point, we should never actually use a type of interest which is not a subtype of the...

My reasoning here is that nullability is different from other supertypea and subtypes. We already accepted that when we made **NonNull**(T) a type of interest when you check for `T`....