Bob Nystrom

> With Dart 3, do you think it's fine if we expand this to suggest using if-case with a type check or non-null check for some situations? Yes! A thousand...

Good catch. We can fix this by having the example catch some fictitious type that `downloadTeam()` would theoretically throw, like: ```dart Future countActivePlayers(String teamName) async { try { var team...

> I think the current tall style might be an improvement. The case in [df97775](https://github.com/dart-lang/dart_style/commit/df977757b58d3544980719f982f09b3be2d1e223) looks better with the first operand on the next line because it makes the indentation...

Right. Currently the formatter's rule is that if a member has a non-empty braced body, it forces a blank line *after* the member, but not before it. I think what...

What rule do you have in mind that would force a blank line between these: ```dart const MyWidget({required this.child}); final Widget child; ```

The old formatter supported this. I'm not opposed to it in principle but when I wrote the new formatter, I ran into a few challenges: **How far to take it?**...

Thanks for the thoughts. > When full automatic comma management is in place, I assume the formatter in this case treats all code as equivalently without whitespace and without trailing...

> So there is no way to override that behavior on small piece of code? If you really want, you can use `// dart format off` and `// dart format...

Yeah, we'll want to sit on this until 3.10 is out. If I forget about this PR, you may need to remind me later. :)

Line breaks inside the header of a `for` loop are hard. I agree that the current formatting isn't beautiful. But I spent a lot of time looking at hand-formatted Flutter...