Bob Nystrom

You're right, this is a missing cell in the table. (The other missing one is switch collection elements.) It's tricky because `if-case` is a riff on `if`. There are no...

> (Note that from a user's perspective, `if` expressions _do_ exist in a collection context, just not anywhere else.) Technically, those aren't expressions either. They're elements. Because the things in...

I'm with @lrhn in that I would like to support destructuring patterns in parameter lists, yes. But Dart 3.0 won't support that. The problem is that the parameter list syntax...

This seems reasonable to me too, but I agree with marking it "patterns-later" so we can get a feel for how the pattern matching features we've already specced fit into...

I have to admit, I'm skeptical that this would be a good fit for Dart. I generally love the idea of using the type system to reason about programs better,...

> So what I'm suggesting that developers could do is to use parameter names like non-private `_x` to indicate that > > 1. you are now providing an actual argument...

> But we could use `this._x as x`: The renaming is explicit and developer-controllable, and anyone who looks up the declaration of the constructor will know what is going on....

I was curious about whether a general rename facility for initializing formals (#3058) would be more useful than supporting only the simple case of allowing `this._foo` to initialize a field...

> @munificent, does the new kind of formatting cause trailing commas to be less relevant (perhaps even useless) in the situations mentioned above?: With the [new style](https://github.com/dart-lang/dart_style/issues/1253), the formatter will...

> I would actually want trailing commas in initializer lists, after a final initializer, but not after a final super-constructor invocation. I mean... if there's a final super-constructor invocation after...