Bob Nystrom

> maybe there are cases where a user would _want_ to format generated code? Turning this around, why *wouldn't* a user want to format generated code? Unless the generator is...

When the [new formatting style](https://github.com/dart-lang/dart_style/issues/1253) ships, you will be able to use [a pair of comments to disable formatting a region of code](https://github.com/dart-lang/dart_style/commit/dd1f7d9695782111da03fee53dba531d114b13ef).

> @munificent That sounds great. When is this going to be released? Unless something goes wrong, it will ship in Dart 3.7, and in the Flutter release that corresponds to...

In principle, yes, this is a thing we could do. Since records can't be implemented or inherited from, we know that every record field access is effectively non-virtual. If we...

Am I reading right that this is basically: * `override` as an optional modifier for instance overrides instead of `@override`. * `override` to mean "augmenting" for non-instance members? If so,...

> The point is that here it isn't. Or rather, there is no "augmentation". > > An overriding class declaration with the same name, in the same library, works mostly...

I just stumbled onto this still-open PR. I guess it's invalid now? Want to close?

> The first type schema was just a hint. > (We need to ensure that it's just a hint, and no compile-time error occurs because some expression's static type doesn't...

> With regards to conflicts with records, what about changing `()` to something else, such as maybe `#()`? That's an interesting idea. We did spend a bunch of time discussing...

> It's a bit late, but I kind of wish Records were the ones who had an extra leading character. Like `final foo = #(1, 2)`. We discussed this, at...