Lasse R.H. Nielsen

I disagree that this is necessarily a syntactic transformation, but we do need to specify what it means. I'd prefer to say that each non-augment declaration introduces a semantic declaration,...

I don't think we should assign a semantics to an augmentation library, separate from the library it's augmenting. Like a part file, it has no meaning except in the context...

> We treat each library augmentation file as an AST but where each identifier has been tagged with the library augmentation that it came from We usually treat the AST...

A sketch of a framework and terminology for specifying the behavior of augmentations is available [here](https://gist.github.com/lrhn/7a81069d2a24042925f63cb3207e1807). The idea is that a syntactic declaration has some properties. We then abstract those...

I have added somewhat larger-in-scope [design proposal](https://github.com/dart-lang/language/blob/main/working/3616%20-%20enum%20value%20shorthand/proposal-lrhn.md). It has some ideas for how to allow more constants than just on the type itself, but it still cannot reach Flutter's `Colors`...

> which is a non-extension type that is also a superinterface of `E` Does it have to be a non-extension type? It should work just as well adding extension types...

With structural assignability, _and_ using the erasure as context type, why not just make it a proper subtype? > `S` \

> I proposed using a keyword to indicate properties like assignability (so we'd have this kind of assignability with an extension type if and only if its declaration starts with...

If we allow function literals inside macro annotations, we should just allow them in any constant expression. There's a request for that, constant function literals, and it would be useful...

If `Code` object literals are needed, then that's another thing we can add generally. Not sure precisely which use-cases to cover, but since kind of quote/quasi-quote-like syntax for delimited Dart...