Allow the type of an object pattern to be inferred when specified as `_`

[eernstg]

Ideas similar to this one have been discussed already when patterns were introduced, but I don't think there's an issue where the proposal has been presented in a concrete form.

We could make object patterns a bit more concise and convenient by using a wildcard _ to indicate the type of the object pattern when it can be inferred:

class const PairClassWithATerriblyLongName(int x, int y);

void main() {
  var pair = PairClassWithATerriblyLongName(2, 3);

  // Using the proposed feature:
  var number = switch (pair) {
    _(x: >= 0, y: >= 0) => 'first',
    _(x: < 0, y: >= 0) => 'second',
    _(x: < 0, y: < 0) => 'third',
    _(x: >= 0, y: < 0) => 'fourth',
  };

  // Compare this to the current syntax:
  number = switch (pair) {
    PairClassWithATerriblyLongName(x: >= 0, y: >= 0) => 'first',
    PairClassWithATerriblyLongName(x: < 0, y: >= 0) => 'second',
    PairClassWithATerriblyLongName(x: < 0, y: < 0) => 'third',
    PairClassWithATerriblyLongName(x: >= 0, y: < 0) => 'fourth',
  };

  print('Found a pair in the $number quadrant');
}

(I'm assuming that we have primary constructors, hopefully we will have them soon.)

It might be claimed that _ causes the code to be less readable than it would have been with the explicit type. However, it's worth noting that when the _ occurs repeatedly at the top level in cases like the above example then it is easy to see that every _ stands for the same type, and it must be the static type of the scrutinee. Similarly, when _ is used in a nested object pattern, e.g., PairClassWithATerriblyLongName(x: _(isEven: true)), the type of the nested object pattern could be rather easy to determine based on the enclosing patterns.

In any case, it will be a matter of style whether _ is an acceptably readable type on any given object pattern, and individual organizations and developers will choose a style for this, just like they are choosing a style for many other things.

The inferred type of an object pattern may include actual type arguments:

class MyClass<X> {
  final X x;
  MyClass(this.x);
}

void main() {
  var xs = MyClass(1); // Inferred as `MyClass<int>(1)`.
  switch (xs) {
    case MyClass(x: var y) when y.isEven:
      print('Got an A!');
  }
}

In the object pattern Myclass(x: var y), the type argument int is inferred. We can see that it is actually int because y.isEven is accepted with no errors, and also because y.isEven is an error when we have MyClass<num>(x: var y). We can also see that the inferred type isn't dynamic, because y.unknownMember is an error.

This should all work the same when we use the proposed feature:

void main() {
  var xs = MyClass(1); // Inferred as `MyClass<int>(1)`.
  switch (xs) {
    case _(x: var y) when y.isEven:
      print('Got an A!');
  }
}

[hydro63]

Seems like a duplicate of #2563.
Edit: issue seems like revisiting the abandoned issue, and contributing possible new ideas.

[eernstg]

Good catch, thanks!

It is similar, but that one was dropped because it used a syntax which is indistinguishable from record patterns. At least, I haven't heard anybody arguing in favor of the record-syntax-means-inferred-object-pattern proposal for a long, long time.

On the other hand, this comment from @samandmoore and this comment from @mraleph in #2563 already mention the syntax _(...).

This means that this issue is indeed an attempt to breathe new life into an idea which was mentioned in #2563, and also to give this idea a dedicated issue of its own.

I think this should be sufficient to justify having this issue.

[eernstg]

@lrhn argues here that

The _ doesn't say "infer" to me. ...
I'd expect case _(foo: pattern) to match whatever the type, basically being an alias for dynamic.

I think the interpretation where an object pattern of the form _(...) means dynamic(...) is plausible, but not very useful. If you really want to use the type dynamic for the receiver of all the getter invocations implied by the contents of this object pattern then you might just as well write dynamic(...) in the first place, and allow _(...) to have a more useful semantics based on inference. I don't think we should spend useful syntactic capital on making dynamic(...) more convenient and less visually detectable than it is already. ;-)

If we interpret the _ as an "accept the default, whatever it is" mechanism then it does makes sense (to me, at least) that an object pattern has _ as a type, and it is implicitly replaced by the matched value type.

[julemand101]

Would we also be able to reduce in scenarios like:

void main() {
  Map<String, int> map = {};

  for (var MapEntry(:key, :value) in map.entries) {
    print('$key : $value');
  }
}

Where we would then be able to do:

  for (var _(:key, :value) in map.entries) {

?

[lrhn]

I propose the syntax .(foo: var x).
That is, use . instead of _ to refer to the context type.

That matches the proposed .foo to refer to static members of the context type.

That is, use . instead of . to refer to the context type.

Tangentially related: if dot stands for the context type, this opens the way to defining a block expression syntax in two steps:

1. Allow the syntax like var x = int { ...; 42}; where int {...} denotes a block expression returning int
2. Allow dot to stand for the "inferred type" of the above, which results in var x = .{ ...; 42};

[TekExplorer]

I'm not really a fan of .

Its kinda small and easily forgotten, whereas _ to me reads "fill in" much like we use for "sign on the line" and... uh... homework.

Alternatively, it can also mean "infer" which could be useful for something like Foo<Bar, _> where we may want to specify some type parameters, but let the rest be inferred.

. would instead find its home in constructor invocation or enum values, such as MyEnum x = .thing; or Foo foo = .parse('...')
where it means "invoke on inferred type", or, literally, _.staticThing
(in other words, static members)

notice the difference? _ is the inferred type, while . is an invocation on that type.

final int i = .parse('1');

enum X {uno, dos}
final X x = .uno;

class const Foo(String str);

void thing() {
  // static member. `.new(...)` becomes a shorthand.
  final Foo foo = .new(switch (x) {
    // static members
    .uno => 'one',
    .dos => 'two', // implies `_.dos` which implies `X.dos`
  });

  return switch (foo /* as Foo */) {
    // infer type `_ = Foo`
    _(str: 'one') => 1,
    _(str: 'two') => 2,
    _(:final str) => str.length,
  };
}

after all, . isn't a type, its an invocation on... something. if we let that something be _ where _ is the type, then it just works

Note: turning _.staticMember into .staticMember can come later

[mateusfccp]

I know this approach is probably easier to parse, but syntax wise I prefer #2563.

for (var _(:key, :value) in map.entries) {}

for (var (:key, :value) in map.entries) {}

That said, if we go with this approach of using a symbol to denote "infer this", I agree with @lrhn that _ does not a good job, even though there are languages that already use them for this kind of thing (for instance, Kind2 uses it for inferring types).

_ has already a wildcard semantic that is very loaded when used with identifiers, and now with patterns wildcards. I think we should think on alternatives.

[TekExplorer]

we cant use the second option because that's a record.

i don't see how _ is overloaded. AFAIK its used as 1. "pattern match any" and later as 2. non-binding variable.

Since we're talking about pattern matching, 2 is irrelevant. additionally, _(...) => is distinct from _ =>, meaning its brand new syntax.

for the case of map.entries, we really should just look to creating an extension that provides an iterable of records instead.

extension KVEntries<K, V> on Map<K, V> {
  Iterable<(K, V)> get kv => entries.map((e) => (e.key, e.value));
}

The "best" solution for this in particular is to turn MapEntry into a record in actuality, but that's a different issue

[mateusfccp]

we cant use the second option because that's a record.

It's not impossible. If you read the discussion in the aforementioned issue, @munificent proposes disambiguation rules that can work, and IMO it would be better.

Since we're talking about pattern matching, 2 is irrelevant.

It's not irrelevant. Even if context can disambiguate syntax, pragmatically speaking, the readability of the syntax is better and easier to quickly grasp if each syntax has a single meaning. This is inevitable in some cases, but this is a case where it can be avoided.

[TekExplorer]

By that logic we can't use . either, since it would then have multiple different meanings.

By using _() it does not overlap with _-as-wildcard nor -as-nonbinding-variable because neither can have parens the way this does, and it also cleanly lines up with explicitly requesting inference in type parameters, which is proposed to use <> which has similar semantics to this, where it means "the implied type"

If we can just use record types outright, then that could be neat, but it feels problematic. It becomes unclear through scanning if the value is a record or an object of implied type.

[mateusfccp]

By that logic we can't use . either, since it would then have multiple different meanings.

Yeah, I never said I think . is a good choice.

Not as terse as what was suggested here, but if we consider something like #3616, we could do

for (var .new(:key, :value) in map.entries) {}

[TekExplorer]

Thats interesting, but wouldn't work, because we aren't checking constructors, (even though it looks like it) we're pattern matching.

Therefore, .new() gives the wrong impression.

I am of the opinion that based on the currently proposed options, _ (which has synergy with explicit inference on types) or the objects-sort-of-as-record thing (which has ambiguity

If anyone has better ideas than this (or hell, worse ones - just to get those juices flowing) then let's see 'em!