Allow inferring the name on object patterns

[munificent]

An earlier version of the patterns proposal used record pattern syntax like (foo: var f, bar: 3) to match any object, and it would simply call the corresponding getters on whatever static type the matched value had. Alas, this left users with no way to actually test if an object is a record (#2218). We fixed that by saying that record pattern only ever matches record objects. If you want to call getters on other objects, you have to use a named object pattern.

This works, but it's verbose in cases where you want to use an object but the type you're destructuring is the same as the matched value type, like:

var map = {1: 'a', 2: 'b'};
for (var MapEntry(:key, :value) in map.entries) {
  ...
}

Here, we already know the static type of the matched value is MapEntry. And we know that the value can never be an actual record since MapEntry isn't a record type. So the object name doesn't add much value here. It would be nice if you could write:

var map = {1: 'a', 2: 'b'};
for (var (:key, :value) in map.entries) {
  ...
}

Of course, that's ambiguous with record patterns. To disambiguate, I would say:

You can omit the type name in an object pattern only when the matched value type is not a record type, Record, or a supertype of Record. When the matched value is any of those types, then the pattern is instead treated as a record pattern that only matches records.

When the matched value is any other type, a record pattern could never successfully match since the value will never be a record, so we instead treat it as an extractor pattern whose inferred type is the matched value type.

We do have to decide this now because the proposal currently doesn't make it an error to have a record pattern in a context where the matched value type means no record will ever appear. You can still write the record pattern, but it just will never match. When we full specify exhaustiveness checking, we might be able to flag this as an unreachable case. If we do that, then we can allow inferred object names in a later release without it being a breaking change.

[lrhn]

This can apply to both declarations and case-matches.

Case matches are the easier: You know the static type of the expression being switched on (switch (expr) or if (expr case ...)) before looking at the pattern.

At that point, if the static type of the incoming value cannot be a record, then an "unqualified extractor pattern" is interpreted as an extractor pattern on that static.
If the incoming value can be a record, then it's either a record type itself, in which case it's trivial, or it's a supertype of Record, which leaves a very limited API to extract from (basically just the Object members). At that point, it's safe to make it a record match. If you want anything else, it's easy to write Object(...) or FutureOr<Object?>(...) instead.

The trickiest one is probably dynamic. If you want to do a completely dynamic match, (x: 2, y: 5), which is matched by any object with an x getter returning 2 and an y getter returning 5, you might have to write dynamic(x: 2, y: 5). I think that's fair, and actually like seeing that this is incredibly dynamic and error prone. (It'll throw if there is no x or y getter, it won't check for existence first).

The assignment is more problematic, var (:x, :y) = e;. The three-step inference algorithm starts by deriving a type schema from the pattern. At this point, the pattern doesn't yet know whether to be a record pattern or an extractor pattern.
I guess defaulting to a record type schema will be safe. If it matters to the type inference of the expression, then it might end up being a record. If not, it probably doesn't hurt.
Then the expression's static type is used to go back and infer the types for the pattern. At that point, we do the same as above. If the RHS ends up being the class Point, that's what we'll be extracting from. The first type schema was just a hint.
(We need to ensure that it's just a hint, and no compile-time error occurs because some expression's static type doesn't match its context type.)

Consider:

class Box<T> {
  T value;
  Box(this.value);
}
void main() {
  var (:double value) = Box(1);
  print(value);
}

Here the type schema of the pattern is ({double value}) (one-named-element record).
The type inference for Box(1) does nothing with that. It then creates a Box<int>(1).
Then we go back, and since the RHS type cannot be a record, we make it Box<int>(:double value).
Then it fails because int, the type of Box<int>.value, is not assignable to double.

There is no good way to pass the expectation that value should be a double to the other side with mentioning Box.
So, there will be shortcomings, where you can't omit the type name, probably mostly around generics.
(That said, I don't think var Box(:double value) = Box(1); would work either, we don't infer a Box<double> context type from the nested patterns on the LHS, which is what would be needed.)

I think it can work. I'm slightly irked by the "arbitrariness". For records and non-record types, it's fine. It's the supertypes of records where the choice feels arbitrary.
(It would be great if we could use {foo: pattern} for extraction instead, but that's also map literal, and any type can implement Map so we can't do something similar with that. Special casing record types is easier because not all types can be supertypes of a record type.)

Also, this all assumes the pattern can be either a record pattern or an extractor pattern.
Not all record patterns can, only those entirely with named properties.
What will we do for:

var (int x, int y) = new Point(1, 2);  // Author forgot the `:`s

Will the LHS just be a record pattern, which doesn't match?
Or will we make it an extractor pattern ... which is then grammatically wrong?
(So, basically, how it will break, not whether.)

[munificent]

The first type schema was just a hint.
(We need to ensure that it's just a hint, and no compile-time error occurs because some expression's static type doesn't match its context type.)

Yes, the original proposal worked that way. When I talked to folks, some people felt it was strange that the context type might end up being discarded and not actually the same as the eventual incoming type, but as far as I know, it wasn't actually problematic.

I think it can work. I'm slightly irked by the "arbitrariness". For records and non-record types, it's fine. It's the supertypes of records where the choice feels arbitrary.

Yeah, but I think those cases will be rare and when they occur, the record pattern is what you want.

Also, this all assumes the pattern can be either a record pattern or an extractor pattern. Not all record patterns can, only those entirely with named properties. What will we do for:

var (int x, int y) = new Point(1, 2);  // Author forgot the `:`s

Will the LHS just be a record pattern, which doesn't match? Or will we make it an extractor pattern ... which is then grammatically wrong? (So, basically, how it will break, not whether.)

I was thinking that I would specify this by making the name in an extractor pattern optional. So instead of saying a record pattern might behave like an extractor, we'd specify that an extractor might look like a record. Then we'd just disambiguate the colliding syntaxes by looking at the matched value type.

But on further thought, that's probably the wrong way to go about it. Because that means we can't disambiguate the syntax until we've done type analysis.

So... I'm not sure. I'll have to think about how to specify this cleanly once my brain is more COVID-free and functional. But, yes, the above case would end up being an error.

[leafpetersen]

After talking a bit with @mit-mit about #1201 , it occurred to me that allowing this could also make field promotion using if case at least marginally better. Consider:

class LongNamedThing {
   int? longNamedField;
}

void myCode(LongNamedThing thing) {
  if (thing.longNamedThing != null) {
     print(thing.longNamedThing!.isEven);
  }
}

With the patterns feature, you can rewrite this as follows:

void myCode(LongNamedThing thing) {
  if (thing.longNamedThing case var longNamedThing?) {
     print(longNamedThing.isEven);
  }
}

which is marginally better, but still requires saying "longNamedThing" twice. Another option would be to write:

void myCode(LongNamedThing thing) {
  if (thing case LongNamedThing(:var longNamedThing?)) {
     print(longNamedThing.isEven);
  }
}

but now you have to write LongNamedThing

With the proposal in this issue, you could presumably write:

void myCode(LongNamedThing thing) {
  if (thing case (:var longNamedThing?)) {
     print(longNamedThing.isEven);
  }
}

which is at least marginal better.

[rrousselGit]

I think this would go a long way toward making patterns smoother to use.
For now, I feel like the syntax is very heavy. It's tempting to fallback to an if/else-if for the sake of readability.

With regards to conflicts with records, what about changing () to something else, such as maybe #()?
Example:

class Foo {
  Bar? get bar;
}
class Bar {
  String name;
}

...

switch (Foo()) {
  case #(bar: #(name: "John"): print('Hello John'); 
}

[munificent]

With regards to conflicts with records, what about changing () to something else, such as maybe #()?

That's an interesting idea. We did spend a bunch of time discussing this syntax and various other ways to make record patterns (and expressions) syntactically distinct. The other place you run into is single-element positional records:

var number = (1);
var recordOfNumber = (1,);

Here, the trailing comma is needed to avoid ambiguity with a parenthesized expression. A different record syntax would avoid that overlap.

But in almost all other widely used languages with tuples and tuple patterns, the syntax is either a parenthesized comma-separated list of fields, or just a comma-separated list of fields. It felt like a large unfamiliarity tax to introduce a different record syntax for Dart given that.

So I think the record syntax works OK. But as you suggest, we could maybe use a different syntax for "inferred object patterns". It's really hard to come up with a syntax that doesn't feel pointlessly unfamiliar, though.

[samandmoore]

I just ran into this today and it was a bummer because the thing I'm destructuring has a multi-word name.

It's really hard to come up with a syntax that doesn't feel pointlessly unfamiliar, though. - @munificent

I totally agree. Personally, I don't hate the #() that @rrousselGit suggested. It's not familiar but it's not entirely surprising.

For another suggestion that might be more intuitive, which is what I think you're looking for, what about borrowing the _ from the wildcard feature for this?

switch (Foo()) {
  case _(bar: _(name: "John"): print('Hello John'); 
}

It may create some grammar ambiguities, or maybe just require some extra read-aheads to parse. That's definitely not my area of expertise, but the _ feels pretty intuitive to me.

Given that I've just been trying to figure out all the flavors of patterns with only cursory glances at the docs, I can say pretty confidently my thought process would likely be:

• I want to match this object. (uses record shorthand) ❌
• Oh, but it's not a record. 🤔
• (types out full class name) 🤔 But that's... long...
• Oh! What happens if I throw an _ in there? ✅

[rrousselGit]

It's a bit late, but I kind of wish Records were the ones who had an extra leading character. Like final foo = #(1, 2).
I think it would've been more intuitive overall, by avoiding stuff like var x = (42) vs var x = (42,) which either creates an int or a tuple.

In any case, I would assume a leading character for inferred type matching should be fine. It kind of reminds me of the it proposal:

list.map({ it.name });