Matthew McDonald

Are there any situations where someone would actually want an implicit `Object?`? If you are going to make a breaking change like this, then why not just make it an...

> As an alternative, we could make an omitted return type mean `void`. That might actually be useful, and meaningful: A function with no return type does not return anything....

C# has similar pattern matching features to dart, except they also have a `not` pattern: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/patterns#logical-patterns ```c# if (input is not null) { // ... } ``` And pattern matches...

I didn't realize this restriction applied also to `Null`. I opened an issue previously about extension types for Function and Record types implementing their representation types. (#3839)

> (I don't know what it would mean to implement `void`, `dynamic` or `Never`.) Well for `Never`, you already can't create an extension type on `Never`, so no need to...

One problem you have to consider is that lazy evaluation is not limited to just `late` variables. Top level variables and static variables are lazily evaluated also. Both of the...

> So all top-level and class static variables are implicitly `late`? They are not implicitly `late`, but they are implicitly lazy. > I was not aware of that one either,...

Personally, I prefer the initializing syntax @lrhn proposed at least for in-body constructors. To me it seems the most consistent with how constructors already work. Note that in the declaring...

> [@mmcdon20](https://github.com/mmcdon20) I think your initializing block should be > ```dart > class Rectangle { > // intitializing > const this({required final int this.height, required final int this.width}); > //...

What if we add a rule that an initializing formal parameter (`this.x`) will create a corresponding field if one does not already exist? The following is already valid code in...