Pattern matching: Allow nullable variables to be defined only in specific cases

[rrousselGit]

Consider:

switch (obj) {
  case Foo():
  case Bar(:final int? property):
}

At the moment, it is not possible to do print(property) within said case, because not all cases define the property variable.
But int? is nullable. Could we instead consider that it is defined but null?

[lrhn]

The current rules for visibility of variables in a multi-case body is that all patterns must introduce equivalent variables.

That's easy to reason about.

What if the variable wasn't final, should it still exist if the other branch is taken?
What if one was that final Super foo and the other final Sub foo, should it still exist on both branches and only be typed as Super in the body? What if they're not final?

If the branches don't agree, don't share a body.
Or do

print(switch (obj) {
  Foo() => null, 
  Bar(: final property) => property,
});

(Also, a hack:

  switch ((obj, null)) {
    case (Foo(), final int? property):
    case (Bar(:final int? property), _):
       // propery is int?
  }

Not a pretty hack, not one I have ever used in the wild, but it's there if you ever need it.
In the general case, you can have (value, nullValue: null, intValue: 0, stringValue: 0) and inject as many default values as you might need into the switch.)

[eernstg]

Here's another hack (potential beauty is in the eye of the beholder) that allows us to bind a variable to null in any object pattern, with zero extra cost in other cases (syntactically and at run time):

// Hack, just keep this one around in some 'utils' library.

extension<X> on X {
  X? get getNull => null;
}

// Example classes.

class Foo {}

abstract class Bar {
  int get property;
}

void main() {
  Object obj = Foo();
  switch (obj) {
    case Foo(getNull: final int? property):
    case Bar(:final int? property):
      print(property);
  }
}

This doesn't cover the ability to pull arbitrary values out of arbitrary patterns (like the record based approach), but you can use case P && Any(getNull: final int? property) (where typedef Any = Object?;) to use getNull even when the pattern P isn't an object pattern.

This use of getNull isn't very readable for a developer who hasn't ever encountered this kind of object pattern, but it should be rather easy to get used to it, if an organization has made the choice to use it, and everybody has seen it now and then.

I guess these hacks serve as support for the claim that the requested behavior (implicitly make missing cases bind final int? property to null) isn't easily expressible, and perhaps deserves to be supported at the language level.

As a language mechanism, it would only be supported when some but not all cases in a shared case scope introduce a variable (same name, same finality, same declared type), and the remaining cases do not introduce a variable with the same name (with any finality and type), and the declared type is nullable.

This would turn some switch statements and expressions into compilable code, where we had previously encountered a compile-time error, which means that it would be a non-breaking change.

It might give rise to bugs because one or more of those cases declare a variable with a similar but different name, but it's only different because of a typo. So the target variable gets bound to null in those mistyped cases, silently, and that might be rather hard to spot during debugging.

The question is whether it's so useful that it justifies the effort needed to make it happen.

[Edit: Object?(...) is a syntax error; I adjusted the example above to use a type alias Any which is the same type, and not a syntax error. This makes the hack even more hacky, but it does work. ;-]

[eernstg]

@rrousselGit, this might be a feature whose implementation and other impacts are so manageable that it's better described as a 'small-feature' than a 'feature'? If it isn't hard then there's no need to make anyone think that it's a big, breaking thing.

[rrousselGit]

I think a different way of looking at this would be:

Could we do a LUB on variables from all cases?

Cf:

switch(x) {
  case MyClass(double: final value):
  case MyClass(integer: final value):
     // value is of type num
}

The scenario described in OP would be an extension of that

[FMorschel]

@rrousselGit, here is the proposal for LUB in patterns:

• Use LUB for or pattern variables #4319