Erik Ernst

> The `onError` parameter of `Future.catchError` is typed as `Function`, because the acceptable signatures of that function cannot be expressed right now. `onError` can either be `FutureOr Function(dynamic)` or `FutureOr...

Good points! First, `augment` and `external` can coexist. The idea is that it should be possible to declare the signature of a function, and an augmenting declaration would then be...

The grammar certainly works hard to allow for `augment external` on getters, setters, functions, and variables ([here](https://github.com/dart-lang/language/blob/main/working/augmentations/feature-specification.md#top-level-augmentations-and-incomplete-top-level-members) for top-level declarations and [here](https://github.com/dart-lang/language/blob/main/working/augmentations/feature-specification.md#class-like-declarations) for members). The [version 1.35 change log entry](https://github.com/dart-lang/language/blob/main/working/augmentations/feature-specification.md#135)...

Interesting! I think, though, that this might already be covered by declaring the parameter group as a [record](https://github.com/dart-lang/language/blob/master/working/0546-patterns/records-feature-specification.md#identity), and using a spread operator. In that sense it could be considered...

The record proposal does not mention the spread operator (which would allow records to be passed in a way that desugars to several separate actual arguments), but it has been...

One requirement which has been noted for the `base` mechanism is that private members must be implemented. The same is true for the proposal in this issue: ```dart // a.dart...

Both proposals are interesting: @lrhn wrote: > I think we should allow this It is indeed very tempting: It adds a small amount of computational abstraction to constant expressions, enabling...

https://dart-review.googlesource.com/c/sdk/+/451560 implements this proposal, and it only fails on tests that are specifically expecting a syntax error at ` ? ` without `':' `. This is exactly the new thing...

Agreeing on @lrhn's comment about parsing being performed without access to type information, I don't think there's much to worry about for these examples from @Jetz72: > Could someone write...

> I definitely would not want `b?[]` and `b?[e1, e2]` to be "list if `b` is true, `null` otherwise", but `b?[e1]` to be a null-aware index operator. Agreed, and it...