Lasse R.H. Nielsen

Sounds like a configurable export based on a package being *available* in the current package configuration, with your package not having a strong dependency on the package. (But it does...

> In that world you would have to compile as if all dependencies were present Which means making the dependencies *be* present, the "weak dependency" would be treated as a...

The test scenario sounds like a "transitive dev-dependency". Except that that doesn't really make sense in the current dependency model. If we have a package which provides libraries for helping...

> Should we just allow this generally, even within a regular class declaration? IMO, yes. If someone *wants* to do it, they can use extensions for the instance member today,...

If we don't allow it in general, we should also not allow it with augmentations. That means explicitly saying that it's an error for a _fully augmented_ class/etc. declaration to...

Or just do: ```dart var first = true; String sep() { if (!first) return ","; first = false; return ""; } var jsonText = """{${ for (var key in map.keys)...

Mostly performance, yes. No need to create the list, just to throw it away again, and no need to create the intermediate string from `.join()`, it can just all be...

The variable initializer case is slightly curious because, as you say, it's not a function being referred to, or even a member, only an expression. The `augmented` doesn't consistently refer...

I would use `augmented + v` for invoking an operator then It's mildly inconsistent to have to use both the name of the augmented operator _and_ the word `augmented`, but...

The `==` is little tricky. I'd say that `augmented == v2` will *directly* invoke the augmented `operator==`, and not do `null`-checking first. That is, the `augment op operand` syntax (`op...