Jacob MacDonald

There are a few different workarounds you can use (haven't seen this one!), but all of them ultimately end up violating the exact principle you set out to achieve by...

Just to clarify what I mean, generally the goal (and specifically the goal in this case IIRC) is to have the flexibilty to safely add members to a final class...

It is also worth noting that this comment `// Could also be in 'src/foo.dart'.` is not correct - the mixin definition would have to exist in the same library as...

If you want it to only be mockable _for yourself_ then I agree putting it in `src/foo.dart`, only exporting `Foo` publicly, and using the approach above is very reasonable. Anybody...

The sealed class version does get quite verbose and all you really gain is the ability to work with mockito. With macros I could see us suggesting a solution like...

> However, I do think `@sealed` is less specific: It gives rise to diagnostic messages about _every_ subtype of `Foo` which isn't in the same package (and I don't know...

> I think I was wrong about how dependent we'd be on codegen to mask the breakage Do generated mocks implement both `noSuchMethod` and also override all members that were...

Even if I thought the semantics of these workarounds were good, I still think that pushing a best practice that results in testing specific types being defined in non-testing libraries...

nice I like it!

I wonder if people will get it confused with `&&` though as this almost reads like a boolean now except with only one `&`?