Make patterns more lenient when destructuring objects into new local variables.

[rrousselGit]

Hello!

Background

Consider the following code:

void main() {
  final [first] = [1, 2, 3];

  print(first);
}

Surprisingly, it throws Bad state: Pattern matching error.

This feels very unexpected to me. I would expect destructuring to be able to pick only one value of a pattern.
That is how destructuring works on other languages such as JS:

const [first] = [1, 2, 3]
console.log(1) // correctly prints 1

I get that the expected syntax is to instead write:

final [first, ...] = [1, 2, 3];

but this feels quite unnatural and error-prone to me. The fact that we get a runtime exception here bothers me quite a bit personally.
I would've never expected an exception to be thrown before running the code.

The same issue appears to happen with records:

var (positional, ) = (1, 2, 3);
var (:named) = (named: 42, another: 21);

Here, we get a compilation error. We're instead expected to write:

var (positional, _, _) = (1, 2, 3);
var (:named, another: _) = (named: 42, another: 21);

For similar reasons, that too feels unexpected to me.

Proposal

Could we make patterns less strict when doing destructuring against new local variables?
Such as implying a ... when doing a list destructuring, or filling in the missing properties when doing a record destructuring.

The fact that we can get possible runtime/compile errors here seems surprising to me. It makes destructuring a bit brittle and not intuitive for folks using destructuring in languages.

To me, there should be no pattern matching involved in the destructuring of objects into variable declarations.
To begin with, we cannot write:

var (name, 42) = ('John', 42)

So the fact that we need to write var (name, _) = seems inconsistent to me.

[mateusfccp]

This is only expected. It's very unintuitive to fo final [first] = [1, 2, 3]; and expect it to work.

The fact that this is a runtime error is obviously not ideal, but it couldn't be different unless we were dealing with some kind of dependent type that knew in compile time the size of the list, which is not the case.

Anyway, I don't think the proposed code should work.

[rrousselGit]

It's very unintuitive to fo final [first] = [1, 2, 3]; and expect it to work.

That's quite literally how JS works though, and Dart is closely tied to JS syntax.

[mateusfccp]

Yeah, it may be, but JS is not the best example of a well designed language.

I prefer a more explicit approach, so using ... is perfectly fine IMO.

One thing that I think we could do is to disallow this case where we get a runtime and force the user to do it with a switch so they have to exhaustively handle explicitly the other case.

[munificent]

We discussed this for lists #2415 and more thoroughly for maps #2861.

Ultimately, this is just a design choice. Either option is reasonable but it's about trying to weigh the trade-offs around which one you make the default (strict or non-strict) and which one you have to opt into. We ultimately decided to make lists and records strict and maps and objects non-strict. The reasons for each choice vary somewhat. There's a summary of most of our thinking here.

With list patterns, the ordered position of the elements is fundamental to how the pattern behaves. It extracts elements based on where they are in the list.

If you have some code that is working correctly on a certain list and the list changes by being longer than it used to be, you have to accommodate that change somehow. If we make list patterns always ignore trailing elements, that silently assumes that this new longer list has appended items you don't care about. But why should the language make that assumption? For all the language knows, the new elements could be at the beginning, or somewhere in the middle.

By having list patterns default to being strict on length, the language no longer has to make that guess (and risk guessing wrong). Instead, it default to only matching exactly what you ask for. And if you want to allow extra elements in the list, it gives you a syntax so you can tell it exactly where you want those extra unused elements to be.

It's not a perfect choice, but I think it balances the trade-offs about as well as we could hope.

[x1z7]

@mateusfccp @munificent how intuitive do you find this:

const duration = '10:30';
final [hour, minutes, ...] = duration.split(':');

In many such cases where you know the exact no of elements you're still forced to spread the "remaining" non-existent elements.

Yeah, it may be, but JS is not the best example of a well designed language.

Absolutely, but they still nailed destructuring.

[munificent]

@mateusfccp @munificent how intuitive do you find this:

const duration = '10:30';
final [hour, minutes, ...] = duration.split(':');

In many such cases where you know the exact no of elements you're still forced to spread the "remaining" non-existent elements.

If you know the length of the list then you aren't forced to spread anything. Just do:

const duration = '10:30';
final [hour, minutes] = duration.split(':');

[x1z7]

@munificent it works now which is great, at the time I WAS FORCED to spread.