Bob Nystrom

Thanks for pointing that out, Sam!

In the [forthcoming](https://github.com/dart-lang/dart_style/issues/1403) [tall style](https://github.com/dart-lang/dart_style/issues/1253), these examples get formatted as: ```dart class RouteDefinition { const factory RouteDefinition.fork( String path, List children, { @Required('When `path` is navigated to, what path within...

cc @dart-lang/language-team to get some eyeballs on this. :)

> I'm starting to think that if we mark the primary constructor as such outside of the parameter list, then we should let every initializing formal, `this.x`, parameter introduce a...

> The slightly extra verbosity may be a downside, but I think it is clearer and more symmetrical than using `novar` (or resignifying the presence/absence of `final`/`var`). With @lrhn's suggestion,...

> Hot take: Do we need the ability to define non-field parameters inside primary constructors? Do we *need* it? No. We don't need any of this. We don't even need...

No news, sorry. We've been focused on higher-value features like extension methods and non-nullable types. I do hope that we get to smaller quality of life features like this at...

No plans currently. We've been focused on much higher priority language features.

In [this comment](https://github.com/dart-lang/language/issues/4396#issuecomment-2960300679), @eernst says: > Similarly, the modifier `const` just before the class name indicates that the constructor is constant, and hence every instance variable must be `final` (so...

> For example, we would presumably not allow instances of that class to be created with a non-constant instance creation, No, I don't think that logic follows. You can place...