Ian Hickson

> > I am told users interacting with the console using a screen reader do not like animations in tools, such as the fast changing timer. We're working on providing...

I could live with that. I worry that it'll be confusing for intermittent failures (they'll never get to see what the failure was), but it's a huge improvement over the...

#110 didn't solve this. It used a different name that won't allow us to unfork.

It'd be neat if you could opt-in to making `final` the default. `{$FINALDEFAULT ON}` or `#pragma final_default on` or `.ALLFINAL` or `use final;` or `from __future__ import everything_final`

In Flutter we've been enforcing the use of `final` everywhere (except `for` loop variables and arguments, cc @pq) for a while, and I've found it really helpful to know immediately...

> They also all had ways to out of that which they then later deprecated and removed so that parameters are only single-assignment Do you have any links to more...

Those seem like pretty compelling arguments, I'm sold.

IDE's don't help when you're trying to understand the code in a YouTube video or on a slide at a conference or whatnot.

FWIW, I 100% agree with the concerns that there's too much complexity here. I would go with only four forms (two of which exist today): ```dart import '../relative/path.dart'; // relative...

I think `.` has to be the separator if we have one (we don't have to have one, we could just not support importing libraries in this way with the...