Leaf Petersen

> Between these two choices, I think I prefer leaving the current behavior as is. I am pretty uncomfortable with this. We can choose to explore this, but to be...

Makes sense to me. I believe we've discussed making deferred loading an web only feature: whether we do so or not, I think it is largely driven by the needs...

Hmm. My general take is that anything which cannot be implemented in the language, is part of the language, and hence needs to be specified as part of it.

I'm not too hung up on this. Agreed that there is a fuzzy line in there - any time you have a foreign code interface you can step outside of...

If you want to think of this in terms of intersection types (which is perfectly fine), then I think the right way to think about may be to also think...

> n terms of intersection types, this means that we have a rather unusual rule: For `X & S`, `X` is consistently ignored and we just consult `S`, No, the...

> How are third parties, such as GitHub, expected to resolve Dart in a post-macro world? It looks like the language team expects third parties to embed a Dart compiler...

Or more succinctly (though not as succinct as `a == b`): ```dart bool bothTheSame(bool? a, bool? b) => switch ((a, b)) { (true, true) => true, (false, false) => true,...

> I do not propose that you can write `this.x` to initialize `int _x;`. I propose that you write `this._x` to initialize `int _x;`, and then we give the parameter...

I wonder if we could make this explicit in the syntax for the parameters? A strawman might be to use `_this.x` to mean "initializing formal, with name `x`, which initializes...