Lasse R.H. Nielsen

If we did have a `namespace ... { ... }` declaration, we'd have to decide on a naming style. We usually use UpperCamelCase for types, and it's probably just consistency...

I would worry if any of those cases ever occurred in production code, so I'm fine with making code dead. That'll probably cause a warning, which is what I really...

An extension struct is not a struct. It's a view. When we get records, you can make a view on a tuple if that's what you want. I see no...

One issue with making `Type` objects generic is that if we get "open type"/type deconstruction functionality, which would let you get the `T` of a `List` as a type variable,...

I would assume that an instance of `Type` represents the type `dynamic`, so it would be surprising if `2.runtimeType` returned `Type` instead of `Type`. If we actually have a `Type`...

The advantage of the `default` approach (or #2232) is that you always have the parameter, you just sometimes don't have a value. That avoids tricky bits like: ```dart foo( if...

My issue with `default` is that it looks like an expression, but can't actually be used everywhere an expression can. You can't do `foo(x: default + 1)`. (Or *can* you?...

I will really prefer not to introduce a *new* way to inspect objects. Getters is how you deconstruct objects. They already exist, and work, and they allow you to control...

Interesting idea. The grammar won't work, `sync* [ .... ]` is currently valid syntax if `sync` is a variable of a type which has a multiplication operator . Probably rare,...

For something like debounce, a more aspect-like approach seems preferable. Say, if you could declaratively wrap a function body with some template code: ```dart class Example { void doSomething() with...