Matan Lurey

From a user perspective, the alternative is "I have to read the CHANGELOG manually", so any sort of warning is better than none. From a developer perspective, I don't really...

🤷🏼 I was asked for my opinion and I gave it - I do think sometimes we spend too much time on a hypothetical perfect - but you/your team own...

I guess to be clear: `// ignore` seems fine for the common case (the alternative/status quo is much worse) and I don't mind if variants are lints/hints/etc.

@bwilkerson: > To be clear, I really just wanted to make sure that we had your opinion about the right question. Just to follow up - I re-read my comment...

I'd encourage thinking about this as P1, as the extension types feature seems incomplete without it. (As mentioned elsewhere, yes the compiler will catch this)

Thanks for the ideas Devon! I'm worried that any process that will take a significant investment into custom CI workflows is not something we can guarantee right now (for reasons)....

Was both sad there wasn't an easy fix to this but appreciative that we're tracking the issue. It is fantastic to be able to use `dart:ffi` directly without a build...

Considering that you can't _use_ this information (i.e. there is no reflective support), what would this accomplish?

At least for that particular API, we decided it was probably wrong. I don't know if I'd push for a language feature to fix the API we created (personally).

> The canceled ones are treated same as failed ones. We should filter those out. How can I filter these out quasi-automatically? Look for the text `Newer commit available`? edit:...