Bob Nystrom

> We shouldn't aim to correct bad performing code, we should aim to write good performing code from the start. I agree completely, but the only way to get there...

> As an aside, are the cases there overlapping? Otherwise why not: I make no claims that my temporary refactoring is optimal or good style. :)

> FWIW, my preference is to call all of the above examples compile time errors, just to keep the interactions with flow analysis simple. I could be wrong, but I...

> I can't find this behavior documented anywhere, but it's clearly deliberate--there's a line in flow analysis that explicitly does it. And I don't remember _why_ we only do it...

If it's OK, @tatumizer, I'll leave this open. We don't currently have plans to support this, but I think it's a reasonable and useful extension of our plans around tuples...

> It would be a hugely breaking change to require every Dart class to implement constructors with the same signature as that of all of its supertypes, and similarly for...

> But if there is no connection between those two subtype relationships then we can't make any assumptions about S having any of the known static members that we know...

> It would make T harder to provide That's exactly right. Because now you are "doing more" with T, so the constraints placed upon it are more stringent.

Sorry for the very long delay. > If I want every one of my repos to have a static String called collectionName, Is there any way to have the abstract...

In your example, @esDotDev, I don't see what value an abstract static declaration provides. You're calling `HomeLink.path` directly, so you'll get an error if it isn't defined there anyway.