Bob Nystrom

We discussed this in the language meeting today. We agree that some expression syntax for accessing positional fields is important. (In particular, I find Leaf's point that without an expression...

A topic we haven't discussed yet that I think could affect this decision is code that is *polymorphic over tuple arity*. Right now, there's no plan to be able to...

> In [#2388 (comment)](https://github.com/dart-lang/language/issues/2388#issuecomment-1218558975) runtime introspection is listed as a potential future enhancement. In that comment, I'm not necessarily assuming that some kind of variadic generics would rely on *runtime*...

OK, the parsing and readability problems of `.0` have convinced me that's the wrong path. Another problem with `[]` is that it could collide with the normal subscript operator: ```dart...

> Would it be possible to use the name of a positional field if a name is provided in the type? No, the positional field name is not part of...

My goal is to have pattern matching consistent with the language's existing behavior. (In other words, I want to retcon Dart's existing local variable declarations and switch cases as if...

> It's slightly odd that the same pattern in two different context means something different, but doesn't bother me too deeply. > > > ```dart > > var [a, b]...

These comments are great but have diverged somewhat from the original question. I think the answer is "yes", the proposal does intend to allow implicit downcasts (which may fail and...

I'm going to go ahead and close this issue because I don't have any more action I intend to take on it, but feel free to re-open if you disagree...

> * Is `== constant` intended to work when the receiver overrides `operator ==`? Yes, I don't see why not. > * Does the proposal eliminate the current error for...