Lasse R.H. Nielsen

Allowing potentially constant/non-singleton object creation in a `const` constructor if we know, for certain, that the constructor will only ever be used as `const`, seems *possible*. We definitely know all...

You can obviously destructure a tuple, but if you are destructuring a tuple *literal*, then you are effectively just doing parallel initialization, and could just as well use two separate...

@tatumizer wrote: > Dart AFAIK always compiles the program from the sources - there's no partial compilation, precompiled libraries, etc. That is not correct. Dart does, at least for some...

It's about being able to *see* where things can fail. If you see `person.jobTitle!`, then you know that a `null` check occurs there. You can look to the surrounding code...

I generally create local variables if I have to check-and-use a nullable instance variable. That is a way to avoid the `!`, it's just a tad verbose. I would very...

Even sealed classes wouldn't take away the getter/field symmetry problem. You'd still have to explicitly mark the field as unchanging, in a way where that can be strictly enforced by...

@rrousselGit Getter/field symmetry works both ways: A client of a class cannot see whether a property is implemented with a user written getter or an implicitly induced field getter (it's...

@rrousselGit > But don't sealed classes qualify as an "opt in"? I don't see how. You're opting in to not *extending* or *implementing* the interface. If that *also* means not...

This looks like a duplicate of "Binding Cast and Check" in https://github.com/dart-lang/language/issues/1191. There might be other similar proposals too.

> What would you recommand to migrate such code? Yes, I would. If passing `null` does not mean the same as passing nothing, I believe that the API is already...